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ABSTRACT 


In  the  summer  of  2008,  the  Global  Combat  Support  System — Marine  Corps  (GCSS-MC) 
breached  both  cost  and  schedule  in  development  of  their  ERP  system.  In  addition.  Navy 
ERP  has  had  problems,  GCSS-Army  has  been  delayed,  and  the  Air  Force  Expeditionary 
Combat  Support  System  (ECSS)  is  currently  rebaselining  their  program.  Why  are  all  of 
these  DoD  ERP  system  development  efforts  having  difficulty  and  is  there  a  better  way  to 
implement  ERP  systems  in  the  DoD? 

This  research  focuses  on  DoD  ERP  implementation  efforts  ongoing  in  the  Army, 
Navy,  Air  Force,  and  Marine  Corps.  A  macro-level  review  of  six  DoD  ERP 
implementations  provides  a  historical  perspective  reflecting  the  difficulty  all  have  had  in 
developing  their  respective  ERP  systems.  A  micro-level  review  of  the  GCSS-MC 
program  identities  systems  engineering  challenges  the  program  has  faced.  The 
conclusion  is  that  all  Service  Components  have  similar  requirements  and  all  struggle  with 
development  of  their  respective  ERP  solution.  Much  money  has  been  and  continues  to  be 
spent  on  ERP  implementation  and  each  implementation  has  taken  much  more  time  than 
was  originally  planned.  It  is  important  for  the  DoD  to  take  a  hard  look  at  how  the  current 
ERP  solutions  have  been  developed  and  determine  alternate  ways  to  develop  similar 
systems  in  the  future.  The  DoD  cannot  afford  the  billions  of  dollars  that  have  been  spent 
on  multiple  system  developments  and  needs  to  figure  out  a  way  to  consolidate  efforts 
between  the  Service  Components.  These  consolidated  efforts  may  provide  not  only  an 
expedited  system  development  effort  but  also  a  common  system  that  can  be  centrally 
managed  and  used  to  breakdown  the  unique  stove  pipe  processes  within  each  Service  and 
transform  logistics  chain  management  as  it  is  known  today. 


v 


THIS  PAGE  INTENTIONALLY  LEFT  BLANK 


vi 


TABLE  OF  CONTENTS 


I.  INTRODUCTION . 1 

A.  BACKGROUND . 1 

B.  PURPOSE . 6 

C.  RESEARCH  QUESTIONS . 6 

D.  BENEFITS  OF  STUDY . 7 

E.  SCOPE  AND  METHODOLOGY . 7 

1.  Review  of  DoD  Service  ERP  Implementation  Efforts . 8 

2.  Review  of  the  GCSS-MC  ERP  Implementation  Effort . 8 

F.  CHAPTER  SUMMARY . 9 

II.  DOD  ERP  IMPLEMENTATION  CHALLENGES . 11 

A.  INTRODUCTION . 11 

B.  SERVICE  ERP  EFFORTS . 12 

1.  Army  ERP  Efforts . 12 

a.  Army  ERP  GAO  Key  Findings . 12 

b.  Army  ERP  Functionality . 14 

c.  Army  ERP  Costs . 1 5 

d.  Army  ERP  Schedules . 1 5 

e.  Army  ERP  Effort  Summary . 1 6 

2.  Navy  ERP  Efforts . 19 

a.  Navy  ERP  GAO  Key  Findings . 20 

b.  Navy  ERP  Functionality . 20 

c.  Navy  ERP  Costs . 22 

d.  Navy  ERP  Schedule . 23 

e.  Navy  ERP  Effort  Summary . 23 

3.  Air  Force  ERP  Efforts . 26 

a.  Air  Force  ERP  GA O  Key  Findings . 2  7 

b.  Air  Force  ERP  Functionality . 27 

c.  Air  Force  ERP  Costs . 28 

d.  Air  Force  ERP  Schedules . 29 

e.  Air  Force  ERP  Effort  Summary. . 29 

4.  Marine  Corps  ERP  Efforts . 32 

a.  Marine  Corps  GAO  Key  Findings . 32 

b.  Marine  Corps  ERP  Functionality . 32 

c.  Marine  Corps  ERP  Costs . 33 

d.  Marine  Corps  ERP  Schedules . 34 

e.  Marine  Corps  ERP  Effort  Summary . 35 

C.  CHAPTER  SUMMARY . 36 

III.  GCSS-MC  SYSTEM  ENGINEERING  IMPLEMENTATION 

CHALLENGES . 41 

A.  INTRODUCTION . 41 

B.  ANALYSIS  OF  ALTERNATIVES . 41 

vii 


C.  REQUIREMENTS  DOCUMENTATION . 43 

D.  REQUIREMENTS . 47 

1.  Functional  Requirements . 47 

2.  T echnical  /  Non-F unctional  Requirements . 49 

E.  CUSTOMIZATION  (RICE) . 52 

F.  GCSS-MC  SCHEDULE  HISTORY . 56 

1.  Pre-Milestone  A . 57 

2.  Milestone  A  Achieved . 58 

3.  Milestone  B  Achieved . 60 

G.  CHAPTER  SUMMARY . 63 

IV.  RESEARCH  ANALYSIS . 65 

A.  INTRODUCTION . 65 

B.  SERVICE  COMPONENT  FUNCTIONAL  ANALYSIS . 65 

C.  SERVICE  COMPONENT  ERP  DEVELOPMENT  ANALYSIS . 68 

D.  GCSS-MC  IMPLEMENTATION  ANALYSIS . 71 

E.  CHAPTER  SUMMARY . 73 

V.  CONCLUSIONS  AND  RECOMMENDATIONS . 75 

A.  CONCLUSIONS . 75 

B.  RECOMMENDATIONS . 78 

1.  Centralized  Design . 81 

2.  Centralized  Build . 82 

3.  Decentralized  Test . 82 

4.  Decentralized  Fielding . 83 

5.  Centralized  Sustainment,  Post-Deployment  System  Support 

(PDSS) . 83 

C.  AREAS  TO  CONDUCT  FURTHER  RESEARCH . 84 

LIST  OF  REFERENCES . 85 

INITIAL  DISTRIBUTION  LIST . 91 


viii 


LIST  OF  FIGURES 


Figure  1.  GCSS-MC  OV-1.  From  [10] . 4 

Figure  2.  GCSS-MC  Operational  Environments.  From  [1 1] . 5 

Figure  3.  Methodology . 8 

Figure  4.  LMP  Timeline.  From  [16] . 15 

Figure  5.  GCSS-Army  Timeline.  From  [16] . 16 

Figure  6.  Navy  ERP  Required  System  Interfaces.  From  [18] . 21 

Figure  7.  Navy  ERP  Life  Cycle  Cost  Estimates.  From  [28] . 22 

Figure  8.  Navy  ERP  Timeline.  From  [28] . 23 

Figure  9.  ECSS  Funding.  From  [17] . 28 

Figure  10.  DEAMS  Funding.  From  [17] . 29 

Figure  11.  GCSS-MC  Program  Cost  Status.  From  [15] . 34 

Figure  12.  GCSS-MC  Program  Schedule  Status.  From  [15] . 35 

Figure  13  GCSS-MC  AOA  Analysis  Results.  From  [33] . 42 

Figure  14.  GCSS-MC  Requirements  Documentation  Tree . 44 

Figure  15.  GCSS-MC  "V-Model".  From  [34] . 45 

Figure  16.  GCSS-MC  Traceability.  From  [34] . 45 

Figure  17.  Fit/Gap  Analysis . 55 

Figure  18.  GCSS-MC  Two  Release  Strategy.  From  [41] . 55 

Figure  19.  GCSS-MC  ORD  Schedule . 57 

Figure  20.  GCSS-MC  2004  AS/AP  Schedule . 58 

Figure  2 1 .  GCSS-MC  CDD  Schedule . 59 

Figure  22.  GCSS-MC  November  2006  AS/AP . 59 

Figure  23.  GCSS-MC  2007  System  Engineering  Plan . 60 

Figure  24.  GCSS-MC  MS  B  APB  Schedule . 60 

Figure  25.  GCSS-MC  CCT  Schedule  Comparisons.  From  [43] . 61 

Figure  26.  GCSS-MC  CCT  Rebaseline  Schedule . 61 

Figure  27.  GCSS-MC  MS  C  System  Engineering  Plan  Schedule . 62 

Figure  28.  GCSS-MC  MS  C  AS/AP  Schedule . 62 

Figure  29.  GCSS-MC  MS  C  APB  Schedule . 63 

Figure  30.  Functional  Hierarchy . 66 

Figure  3 1 .  Marine  Corps  Schedule  Trend . 72 

Figure  32.  ERP  Development  Recommendation . 81 


IX 


THIS  PAGE  INTENTIONALLY  LEFT  BLANK 


x 


LIST  OF  TABLES 


Table  1.  Army  ERP  Summary . 18 

Table  2.  Navy  ERP  Summary . 25 

Table  3.  Air  Force  ERP  Summary . 31 

Table  4.  GCSS-MC  ERP  Summary . 36 

Table  5.  DoD  Services  Implementation  Summary . 37 

Table  6  AOA  Results  Summary.  From  [33] . 42 

Table  7.  GCSS-MC  Block  Definition.  After  [31] . 46 

Table  8.  GCSS-MC  Functional  Requirement  Count.  After  [34] . 49 

Table  9.  GCSS-MC  Technical  Non-Functional  Requirement  Count.  After  [34] . 5 1 

Table  10.  O A  Phase  Fit-gap  Requirements . 54 

Table  11.  RICE  Allocation . 56 

Table  12  Service  Component  Functional  Comparison . 67 

Table  13.  Service  Component  Commonality . 70 

Table  14.  GCSS-MC  Program  Challenges . 73 

Table  15.  ERP  Implementation  Recommendation  Summary . 76 


xi 


THIS  PAGE  INTENTIONALLY  LEFT  BLANK 


LIST  OF  ABBREVIATIONS  AND  ACRONYMS 


AIM 

Application  Implementation  Methodology 

AIT 

Automated  Identification  Technology 

AS/AP 

Acquisition  Strategy  /  Acquisition  Plan 

CARD 

Cost  Analysis  Requirements  Description 

CCT 

Critical  Change  Team 

CDD 

Capability  Development  Document 

COBOL 

Common  Business-Oriented  Language 

CONOPS 

Concept  of  Operations 

COTS 

Commercial-Off-The-Shelf 

CSS 

Combat  Service  Support 

DEAMS 

Defense  Enterprise  Accounting  and  Management  System 

DoD 

Department  of  Defense 

DRR 

Design  Readiness  Review 

EA 

Enterprise  Architecture 

ECSS 

Expeditionary  Combat  Support  System 

eLog2 1 

Expeditionary  Logistics  for  the  21st  century 

ERP 

Enterprise  Resource  Planning 

FOC 

Full  Operational  Capability 

FRP 

Full  Rate  Production 

FUE 

Field  User  Evaluation 

GAO 

General  Accounting  Office 

GCSS-A 

Global  Combat  Support  System  -  Army 

GCSS-MC 

Global  Combat  Support  Services  -  Marine  Corps 

I 

Intennediate 

IA 

Information  Assurance 

ICP 

Inventory  Control  Point 

ICD 

Initial  Capabilities  Document 

IT 

Information  Technology 

JDA 

Joint  Data  Element 

JFMIP 

Joint  Financial  Management  Improvement  Program 
xiii 

JTA 

Joint  Technical  Architecture 

KPP 

Key  Performance  Parameter 

LCM 

Logistics  Chain  Management 

LMP 

Logistics  Modernization  Program 

MA 

Mission  Area 

MAGTF 

Marine  Air  Ground  Task  Force 

MAIS 

Major  Automated  Information  Systems 

MEF 

Marine  Expeditionary  Force 

MEU 

Marine  Expeditionary  Unit 

MNS 

Mission  Need  Statement 

MQR 

MAIS  Quarterly  Report 

MS 

Milestone 

MTMC 

Military  Traffic  Management  Command 

NR 

Net  Ready 

OA 

Operational  Analysis 

ORD 

Operational  Requirements  Document 

OV 

Operational  View 

RFA 

Resource  Financial  Accounting 

RFID 

Radio  Frequency  Identification 

RICE 

Reports,  Interfaces,  Conversions,  Extensions 

PDSS 

Post  Deployment  Software  Support 

SASSY 

Supported  Activity  Supply  System 

SCOR 

Supply  Chain  Operations  Reference 

SE 

Systems  Engineering 

SEP 

System  Engineering  Plan 

SFIS 

Standard  Financial  Information  Structure 

SSA 

Supply  Support  Activity 

SSS 

System  Subsystem  Specification 

TAV 

Total  Asset  Visibility 

u.s. 

United  States 

WWW 

World  Wide  Web 

XIV 


EXECUTIVE  SUMMARY 


On  August  7,  1990,  the  deployment  of  United  States  (U.S.)  forces  begun  under  Operation 
DESERT  SHIELD  [1].  Iraq’s  invasion  of  Kuwait  triggered  the  largest  rapid  deployment 
of  U.S.  forces  and  supplies  in  history  for  the  planning  and  movement  of  troops, 
equipment,  and  supplies  as  required  by  Operation  Desert  Shield/Storm  [2].  Such  a 
significant  movement  of  resources  to  support  combat  operations  requires  the  use  of 
Information  Technology  (IT)  systems  to  track  and  manage  the  logistics  chain  for  all 
supplies  and  scheduling  of  maintenance  within  the  theater  of  operation. 

The  use  of  ERP  systems  in  the  DoD  is  becoming  the  method  of  choice  to  develop 
small  increments  of  capability  rapidly.  The  old  method  of  developing  a  large  amount  of 
capability  in  one  increment  is  too  costly,  takes  too  long,  and  may  possibly  result  in 
implementing  out-dated  technology  by  the  time  the  software  is  released  for  use.  An  ERP 
system  can  be  developed  one  business  application  at  a  time  and  provide  a  foundation  for 
all  other  business  applications  to  be  added  later. 

Each  Service  Component  of  the  DoD  is  essentially  trying  to  accomplish  the  same 
goal  in  modernizing  their  aging  logistics  IT  systems.  Functionally,  each  Service 
Component  is  developing  redundant  capability.  Development  of  logistics  ERP  systems 
in  the  DoD  have  been  plagued  by  cost  overruns  and  schedule  delays  in  the  Army,  Air 
Force,  Navy,  and  Marine  Corps.  All  Services  have  experienced  similar  program 
management  and  system  engineering  challenges  recognized  by  the  GAO  and  continue  to 
struggle  with  development  of  their  ERP  systems.  With  the  GAO  identifying  several 
weaknesses  in  each  independent  ERP  development  and  with  the  common  technical 
challenges  evident  across  the  DoD,  would  it  make  sense  to  develop  only  one  ERP  system 
for  use  across  all  Service  Components  instead  of  developing  multiple  independent 
Service  unique  ERP  systems? 

This  thesis  analyzes  six  of  the  logistics  ERP  efforts  currently  ongoing  in  the  DoD 
and  provides  an  analysis  to  support  the  development  of  a  single  integrated  ERP  system  to 
be  used  by  all  four  Services. 
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I.  INTRODUCTION 


A.  BACKGROUND 

On  August  2,  1990,  the  Iraqi  Republican  Guard  invaded  Kuwait  and  seized 
control  of  that  country.  On  August  7,  the  deployment  of  United  States  (U.S.)  forces  that 
became  known  as  Operation  DESERT  SHIELD  began  [1],  Iraq’s  invasion  of  Kuwait 
triggered  the  largest  rapid  deployment  of  U.S.  forces  and  supplies  in  history  for  the 
planning  and  movement  of  troops,  equipment,  and  supplies  as  required  by  Operation 
Desert  Shield/Stonn  [2],  By  1  February  1991,  less  than  6  months  into  deployment,  the 
Transportation  Command  had  moved  about  440,000  passengers,  3  million  tons  of  unit 
equipment  and  supplies,  and  4.2  million  tons  of  fuel  supplies  to  Southwest  Asia  in 
preparation  for  offensive  action  against  Iraq  [2]. 

In  2002,  the  United  States  and  the  United  Kingdom  claimed  Iraq  possessed 
weapons  of  mass  destruction  and  posed  a  threat  to  their  security  and  that  of  their  allies 
and  Operation  Iraqi  Freedom  (OIF)  began  on  March  20,  2003  [3].  Between  1  April  2003 
and  June  2003,  the  Military  Traffic  Management  Command  (MTMC)1  delivered  42.2 
million  meals  to  Iraq,  loaded  cargo  covering  15  million  square  feet,  transported  1.5 
million  tons  of  equipment  and  cargo,  and  moved  98,890  containers  [4].  Logistics  support 
during  OIF  was  not  very  timely.  The  logistics  system  “pull”  processes  depended  on  line- 
of-sight  communications  that  broke  down  due  to  lack  of  connectivity  required  to  assure 
fulfillment  of  end-user  materiel  requests.  This  problem  was  resolved  by  emphasizing  a 
"push"  system  that  pushed  materiel  forward  without  waiting  for  a  request.  While  the 
ability  to  identify  what  containers  arriving  in  theater  were  carrying  was  clearly  and 
generally  much  better  than  a  decade  earlier  in  Operation  Desert  Storm,  asset  visibility 
after  in-theater  distribution  declined  dramatically,  probably  due  in  part  to  the  emphasis  on 
pushing  materiel  forward  [5]. 


1  MTMC  is  a  Major  Army  Command  (MACOM)  that  is  the  overland  lift  component  and  primary 
traffic  manager  for  USTRANSCOM  [6], 
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The  significant  movement  of  resources  to  support  combat  operations  required  the 
use  of  Information  Technology  (IT)  systems  to  track  and  manage  the  logistics  chain  for 
all  supplies  and  scheduling  of  maintenance  within  the  theater  of  operation.  Desert  Shield, 
Desert  Storm,  and  Operation  Iraqi  Freedom  proved  to  be  key  events  in  providing  valuable 
lessons  learned  in  how  well  the  United  States  military  IT  systems  supported  logistics 
chain  management.  During  combat  operations,  the  Marine  Corps  IT  ground  logistics 
systems  did  not  communicate  well,  were  not  integrated,  ran  very  slowly  with  significant 
lag  times,  and  provided  uncertain  or  unreliable  data.  The  inefficiencies  and  inaccuracies 
of  the  IT  systems  resulted  in  multiple  supplies  being  ordered  with  the  inability  to 
accurately  track  and  distribute  the  supplies.  Something  had  to  be  done  to  modernize  the 
Marine  Corps  ground-based  logistics  IT  systems;  thus,  the  Global  Combat  Support 
System  (GCSS-MC)  program  was  initiated  [7]. 

The  GCSS-MC  IT  system  is  being  designed  to  modernize  the  Marine  Corps 
Logistics  IT  capability.  It  is  intended  to  provide  the  capabilities  to  execute  Marine  Air 
Ground  Task  Force  (MAGTF)  Combat  Service  Support  (CSS)  in  expeditionary  and  joint 
environments.  It  will  improve  logistics  chain  management  effectiveness  and  efficiency 
and  will  provide  actionable  combat  support  information  to  leadership.  Existing  Marine 
Corps  IT  logistics  systems  are  numerous  and  many  are  over  30  years  old.  Support  for 
these  antiquated  systems  is  disappearing.  Several  of  the  Marine  Corps  ground  based 
logistics  systems  were  developed  using  the  Common  Business-Oriented  Language 
(COBOL)  programming  language  developed  in  1959  [8].  One  example  is  the  Supported 
Activity  Supply  System  (SASSY).  It  is  a  mainframe  system  developed  in  the  1970s 
using  the  COBOL  programming  language;  it  is  still  in  use  today.  SASSY  is  hard  to  use, 
contains  inaccurate  data,  and  does  not  efficiently  support  the  war  fighter  [9],  It  is 
becoming  increasingly  difficult  to  support  as  the  software  requires  much  patching  and  the 
COBOL  SASSY  programmers  are  becoming  harder  to  find  and  maintain  in  the  work 
force.  The  new  GCSS-MC  system  is  being  built  using  the  Commercial-Off-The-Shelf 
(COTS)  Oracle  lli  E-Business  Suite.  This  is  an  Enterprise  Resource  Planning  (ERP) 
software  that  will  not  only  address  the  immediate  need  of  an  integrated  supply  and 
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maintenance  system,  but  will  be  the  foundation  for  the  integration  and  replacement  of 
other  Marine  Corps  logistics  systems  that  currently  provide  warehouse,  transportation, 
and  many  other  logistics  functionality. 

Operationally,  the  GCSS-MC  software  will  allow  Marines  to  accurately  capture 
data  within  a  shared  data  environment  via  a  secure  connection  using  the  World  Wide 
Web  (WWW).  It  will  allow  the  use  of  Automated  Identification  Technology  (AIT) 
devices,  such  as  hand  held  scanners  and  passive  and  active  Radio  Frequency 
Identification  (RFID)  scanners,  to  input  data  into  a  centralized  shared  data  environment. 
Users  who  are  in  geographic  regions  with  good  Internet  connectivity  will  have  direct 
access  to  the  shared  data  environment.  Users  who  are  deployed  in  remote,  austere 
environments  will  have  a  local  instance  of  GCSS-MC  that  will  be  able  to  communicate 
back  to  the  centralized  shared  data  environment  when  communications  are  up  and 
operational  [7],  The  Operational  View  (OV),  OV-1,  is  shown  in  Figure  1  [10].  Figure  2 
shows  the  flow  of  infonnation  from  the  Enterprise  Server  located  in  the  continental 
United  States  to  the  forward  deployed  units  in  an  austere  environment  [11]. 
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Figure  1.  GCSS-MC  OV-1.  From  [10] 


4 


'V 


X 


Logical  Logistics  Information  Flow 


Expeditionary  Network  Environment  -  Tier  1 


Expeditionary  Notwork  Environment  -  Tier  2 


Naval  Network  Environment 


Garrison  Network 
Environment 


GCSS-MC 

Enterprise 


Physical  Logistics  Information  Flow 


Latency:  High 

Bandwidth  to  GCSS-MC:  Low 
Primary  Available  Network:  SIPRNET 


Network  Characteristics 


Latency:  Medium 
Bandwidth  to  GCSS-MC:  Medium 
Primary  Available  Network:  SIPRNET 


NetworkCharacteristigg 

Latency:  Medium 
Bandwidth  to  GCSS-MC:  High 
Primary  Available  Network:  NIPRNET 


Network  Characteristics  (Naval) 


Latency:  Medium 
Bandwidth  to  GCSS-MC:  Low 
Primary  Available  Network:  SIPRNET 


Figure  2.  GCSS-MC  Operational  Environments.  From  [11] 
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B. 


PURPOSE 


The  use  of  ERP  systems  in  the  DoD  is  becoming  the  method  of  choice  to  develop 
small  increments  of  capability  rapidly.  The  old  method  of  developing  a  large  amount  of 
capability  in  one  increment  is  too  costly,  takes  too  long,  and  may  possibly  result  in 
implementing  out-dated  technology  by  the  time  the  software  is  released  for  use.  An  ERP 
system  can  be  developed  one  business  application  at  a  time  and  provide  a  foundation  for 
all  other  business  applications  to  be  added  later.  According  to  Parr  and  Shanks  [12],  an 
ERP  may  be  implemented  in  one  of  three  ways.  The  ERP  may  be  implemented  in  its 
entirety,  but  it  is  very  complex  and  can  take  up  to  seven  years  to  implement.  The  ERP 
may  be  implemented  using  only  a  core  module  without  any  business  process 
reengineering;  it  is  relatively  inexpensive  but  may  not  provide  all  of  the  needed 
functionality.  Alternatively,  the  ERP  may  be  implemented  using  only  a  selection  of  its 
core  ERP  modules  along  with  significant  business  process  reengineering.  This 
methodology  is  exactly  what  the  Marine  Corps  decided  to  do,  implement  the  supply  and 
maintenance  management  capability  of  the  Oracle  E-Business  ERP  in  one  small 
increment  and  defer  the  development  of  other  business  areas  such  as  Warehousing, 
Transportation,  Planning,  Finance,  Human  Resources,  and  Engineering  to  other 
increments.  In  particular,  the  Marine  Corps  has  decided  to  develop  capabilities  to 
address  immediate  ground  based  logistics  chain  management  shortfalls  as  defined  by  the 
requirements  in  the  GCSS-MC  Capability  Development  Document  [13].  The  purpose  of 
this  thesis  is  to  investigate  the  ERP  development  efforts  in  DoD,  understand  what  makes 
implementation  of  these  development  efforts  so  difficult,  and  provide  a  recommendation 
as  to  an  alternate  way  to  develop  and  implement  a  single  ERP  system  across  all  of  the 
DoD. 


C.  RESEARCH  QUESTIONS 

The  DoD  has  selected  two  main  suites  of  software  for  their  logistics 
modernization  ERP  efforts.  The  Army  and  Navy  have  selected  SAP  and  the  Air  Force 
and  Marine  Corps  have  selected  the  Oracle  E-Business  Suite.  Both  ERP  solutions  allow 
the  incremental  development  of  capability  within  the  software  suite.  In  the  case  of 
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GCSS-MC,  the  Oracle  product  was  best  suited  to  satisfy  both  the  functional  and  technical 
capabilities  as  described  the  GCSS-MC  CDD  [14].  The  Marine  Corps’  initial  focus  is 
only  on  the  supply  and  maintenance  management  functionality.  By  first  addressing  this 
limited  functionality,  the  Program  Office  increased  potential  success  of  meeting  schedule 
timelines  within  budget.  However,  since  the  inception  of  the  GCSS-MC  program,  the 
development  effort  has  still  been  prone  to  cost  and  schedule  overruns  [15]. 

The  following  questions  will  be  analyzed: 

•  What  are  the  DoD  ERP  IT  system  implementation  challenges  in  the  Army, 
Air  Force,  Navy,  and  Marine  Corps? 

•  What  are  the  GCSS-MC  system  engineering  technical  and  functional 
challenges  with  regards  to  the  design  and  build  of  the  GCSS-MC  system? 

D.  BENEFITS  OF  STUDY 

Development  of  ERP  systems  in  the  DoD  have  been  plagued  by  cost  overruns  and 
schedule  delays  in  the  Army,  Air  Force,  Navy,  and  Marine  Corps  as  documented  in 
several  GAO  reports  [15,  16,  17,  18].  This  thesis  will  review  and  analyze  the  ERP 
development  efforts  of  those  services  at  a  high  level  as  well  as  review  and  analyze  details 
of  the  GCSS-MC  program  development  effort.  Implementation  challenges  will  be 
identified  to  highlight  the  difficulties  that  DoD  ERP  programs  experience  and  will  serve 
as  data  for  a  recommendation  of  how  to  implement  future  DoD  ERP  developments. 

E.  SCOPE  AND  METHODOLOGY 

The  scope  for  this  research  focuses  on  DoD  ERP  implementation  efforts  ongoing 
in  the  Army,  Navy,  Air  Force,  and  Marine  Corps.  A  macro  review  of  six  DoD  ERP 
implementations  provides  a  historical  perspective  reflecting  the  difficulty  all  have  had  in 
developing  their  respective  ERP  systems.  A  micro  review  of  the  GCSS-MC  program 
provides  some  of  the  detailed  systems  engineering  challenges  the  program  has  faced. 
The  methodology,  shown  in  Figure  3,  consists  of  performing  two  main  steps  resulting  in 
a  collection  of  DoD  ERP  implementation  challenges. 
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Figure  3.  Methodology 


1.  Review  of  DoD  Service  ERP  Implementation  Efforts 

The  Army  is  developing  GCSS-Army  and  the  Logistics  Modernization  Program 
(LMP),  the  Air  Force  is  developing  Expeditionary  Combat  Support  System  (ECSS)  and 
Defense  Enterprise  Accounting  and  Management  System  (DEAMS),  the  Navy  is 
developing  Navy  ERP,  and  the  Marine  Corps  is  developing  GCSS-MC.  Each  service  has 
had  difficulties  in  developing  their  ERP  system.  This  thesis  examines  each  service’s 
difficulties  at  a  macro  level  and  identifies  challenges  in  DoD  ERP  developments  in 
general. 

2.  Review  of  the  GCSS-MC  ERP  Implementation  Effort 

This  thesis  reviews  GCSS-MC  technical  and  functional  requirements  and 
provides  a  basis  for  the  amount  and  scope  of  capability  that  the  Marine  Corps  is  trying  to 
develop.  The  GCSS-MC  requirements  are  very  unique  than  those  in  the  private  sector. 
The  nature  of  the  Marine  Corps  to  deploy  troops  on  the  move  in  austere  environments  is 
very  different  than  the  private  sector’s  stationary  brick  buildings  and  warehouses.  It  is 
the  uniqueness  of  those  requirements  and  the  complexity  behind  the  implementation  of 
those  requirements  that  cause  much  of  the  program’s  cost  overruns  and  schedule  delays. 
The  GCSS-MC  requirements  are  analyzed  for  technical  complexity  and  scope  of  effort. 
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F.  CHAPTER  SUMMARY 

This  chapter  introduces  the  Marine  Corps  challenges  in  management  of  USMC 
logistics  chain  management  using  IT  systems  that  are  more  than  30  years.  The  use  of 
these  IT  systems  during  Desert  Shield,  Desert  Storm,  and  Operation  Iraqi  Freedom 
proved  that  these  antiquated  systems,  while  effective  for  immediate  war  time  situations, 
could  actually  be  more  efficient  and  beneficial  to  the  war  fighter  if  redesigned  using  a 
distributed,  integrated  IT  system.  Modernization  of  logistics  chain  management  IT 
systems  provides  a  more  reliable  and  accurate  logistics  management  capability  that  the 
war  fighter  desperately  needs. 

Answers  to  research  questions  require  analysis  of  ERP  system  implementations 
currently  within  the  DoD  to  understand  the  system  engineering,  technical,  and  functional 
challenges  that  cause  program  cost  overruns  and  schedule  delays.  Analysis  of  GCSS-MC 
system  engineering  requirements  development  identifies  challenges  that  should  be 
avoided  by  the  DoD  in  the  development  of  future  ERP  systems. 

Chapter  II  provides  a  collection  of  Army,  Navy,  Air  Force,  and  Marine  Corps 
ERP  implementation  information  in  terms  of  GAO  findings,  functionality,  cost,  and 
schedule.  This  comparison  serves  as  the  foundation  to  illustrate  the  difficulties  that  these 
DoD  services  have  had  in  implementing  ERP  systems. 

Chapter  III  provides  a  review  of  the  GCSS-MC  ERP  implementation  effort.  The 
program’s  systems  engineering  challenges  are  identified  in  the  areas  of  requirements 
development  and  COTS  customization.  Functional  and  technical  requirements  are 
analyzed  with  respect  to  complexity  and  the  amount  of  customization  required  to  the 
COTS  software  to  provide  the  required  Marine  Corps  business  process  functionality. 

Chapter  IV  analyzes  at  a  high  level  the  implementation  challenges  of  all  service 
ERP  efforts  as  well  as  the  GCSS-MC  systems  engineering  challenges.  All  of  which  serve 
as  potential  indicators  supporting  a  recommendation  of  developing  a  single  ERP  system 
to  be  used  by  all  Service  Components. 
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Chapter  V  provides  conclusions  and  makes  a  recommendation  as  to  how  DoD 
should  develop  a  single  ERP  system  implemented  across  all  Services.  It  also  makes 
recommendations  as  to  areas  to  conduct  further  research. 
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II.  DOD  ERP  IMPLEMENTATION  CHALLENGES 


A.  INTRODUCTION 

The  Department  of  Defense  set  a  goal  over  30  years  ago  to  obtain  total  asset 
visibility  (TAV).  Per  a  GAO  report  [19],  the  DoD  planned  to  have  the  total  asset 
visibility  capability  achieved  by  2004  and  as  of  July  2007  was  still  unsuccessful  [16]. 
DoD’s  new  target  date  to  achieve  TAV  is  now  2010  [19].  To  meet  the  TAV  goal,  the 
Department  of  Defense  has  taken  on  the  development  of  several  ERP  implementations  all 
providing  a  wide  array  of  capability  unique  to  each  service.  Each  service’s 
implementation  is  designed  to  modernize  business  systems  mainly  focusing  on  logistics 
management  of  assets  and  financial  tracking  of  those  assets.  All  use  ERP  software  from 
either  Oracle  or  SAP,  but  each  with  different  levels  of  scope  and  functionality  designed 
to  replace  existing  legacy  logistics  IT  systems.  Many  of  these  legacy  systems  have  been 
in  service  for  over  30  years  and  support  for  these  systems  is  becoming  scarce.  While 
these  systems  may  be  relatively  inexpensive  to  maintain  as  individual  systems,  the  price 
is  high  in  terms  of  data  being  stove  piped,  inaccurate,  or  not  accessible  in  a  timely 
manner.  Research  and  analysis  of  current  legacy  systems  and  the  reason  for  replacing 
them  is  discussed  further  in  Chapter  IV. 

Since  1995,  the  GAO  designated  DoD's  business  systems  modernization  as  high 
risk  [18].  The  GAO  points  out  that  there  are  many  challenges  involved  with  DoD  ERP 
implementation.  Programs  are  not  aligned  to  a  DoD  business  enterprise  architecture  that 
is  not  fully  defined.  Program  management  is  weak  in  the  areas  of  capturing  quantitative 
data  used  to  assess  overall  effectiveness  of  the  overall  effort.  Programs  often  provide 
their  own  internal  form  of  verification  and  validation  and  do  not  rely  on  those  who  are 
truly  independent  of  the  program  to  give  an  honest  assessment.  Also,  best  business 
practices  need  to  be  applied  to  provide  appropriate  management  oversight  within  the 
Department  of  Defense  to  ensure  programs  stay  on  track  [18]. 

The  following  sections  describe  existing  DoD  ERP  logistics  implementation 
efforts  in  the  Army,  Navy,  Air  Force,  and  Marine  Corps  in  terms  of  documentation, 
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capability,  schedules,  and  cost.  All  of  the  programs  are  attempting  to  transform  the  way 
the  services  perform  the  business  of  logistics  management  and  all  have  experienced 
problems,  both  technical  and  programmatic,  in  the  implementation  of  their  respective 
ERP  systems.  This  infonnation  shows  that  Army,  Navy,  Air  Force  and  Marine  Corps 
logistics  IT  ERP  development  efforts  have  experienced  several  design  and  development 
problems  that  need  to  be  understood  and  addressed  in  future  DoD  ERP  development 
efforts. 

B.  SERVICE  ERP  EFFORTS 

ERP  development  effort  information  was  collected  from  the  Anny,  Navy,  Air 
Force,  and  Marine  Corps  in  four  main  areas  of  interest;  documentation,  functionality,  cost 
and  schedule.  This  infonnation  establishes  a  trend  regarding  service  ERP  efforts  in  terms 
of  cost  overruns  and  schedule  delays. 

1.  Army  ERP  Efforts 

The  Anny  is  modernizing  its  logistics  business  processes  in  order  to  provide  total 
asset  visibility  by  implementing  two  ERP  efforts.  They  are  the  Global  Combat  Support 
System-Army  (GCSS-Anny),  and  the  Logistics  Modernization  Program  (LMP).  These 
ERP  efforts  will  modernize  the  Anny’s  logistics  IT  systems  that  are  over  30  years  old. 
The  GCSS-Anny  program  is  an  AC  AT  1-D  program  [20]  and  is  a  tactical  effort  that  will 
integrate  the  Anny’s  supply  chain,  provide  equipment  readiness  reports,  and  get  cunent 
status  on  maintenance  actions  and  supplies  in  support  of  the  Warfighter  [21].  LMP  is  a 
wholesale  effort  that  integrates  the  Army’s  supply  chain  and  includes  the  capability  to 
track  maintenance  activities,  as  well  as  provides  inventory  management,  transportation, 
and  warehousing  functionality  [21].  The  following  paragraphs  highlight  the  difficulties 
the  Army  has  had  in  developing  their  ERP  solutions  with  respect  to  GAO  key  findings, 
functionality,  cost,  and  schedule. 

a.  Army  ERP  GAO  Key  Findings 

There  are  many  products  that  are  required  to  fully  document  the 
requirements  of  any  program.  Architecture  products  are  key  to  not  only  identifying  the 
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current  system  and  process  functionality  but  also  the  future  or  desired  functionality  the 
newly  developed  system  is  to  provide.  Over  the  years,  the  GAO  has  documented  several 
findings  regarding  the  inadequacy  of  architecture  development  in  the  DoD.  In  2003,  the 
GAO  identified  that  the  DoD  had  yet  to  establish  adequate  integrated  architecture 
governance  structure  and  process  controls  [22].  In  2006,  the  GAO  developed  an 
architecture  management  framework  to  increase  the  effectiveness  of  managing 
architecture  programs  [23].  In  2007,  the  GAO  identified  two  critical  elements  that  the 
Army  needed  to  successfully  implement  the  Army  logistics  ERP;  they  are  an  Army  level 
Enterprise  Architecture  (EA)  and  a  Concept  of  Operations  (CONOPS)  [16]. 

The  EA  is  a  key  document  that  provides  a  blueprint  for  organizational 
change.  It  defines  models  that  represent  two  states  of  architecture.  One  model  represents 
how  the  Army  operates  today;  the  other  model  describes  how  the  Army  intends  to  operate 
in  the  future.  The  EA  should  also  include  a  plan  on  how  the  Army  should  transition  from 
today’s  operations  to  the  future  operations.  Without  an  EA,  interfaces  and  dependencies 
cannot  effectively  be  managed  [16]. 

The  CONOPS  is  the  key  document  that  describes  how  the  new  system 
intends  to  operate  to  provide  total  asset  visibility.  It  details  how  decisions  are  to  be  made 
as  well  as  lay  out  the  new  business  processes  the  ERP  solution  requires  to  operate  in. 
Without  a  CONOPS,  the  Army  will  have  a  difficult  time  in  describing  the  enterprise  view 
of  its  new  systems  as  well  as  not  describing  the  total  asset  visibility  or  supply  chain 
management  processes  the  Army  intends  to  satisfy  using  the  new  ERP  systems  [16]. 
Documentation  of  the  new  business  processes  should  allow  the  Army  to  take  advantage 
of  the  COTS  product’s  ability  to  transform  the  Army’s  business  processes. 

Both  the  EA  and  the  CONOPS  are  important  documents  and  provide  the 
underlying  foundation  required  to  understand  the  architecture  and  operation  of  the  ERP 
system.  Per  the  GAO  reports,  incomplete  or  inaccurate  information  in  these  documents 
could  be  contributors  for  cost  overruns  and  delays  in  schedule. 
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b.  Army  ERP  Functionality 

The  Logistics  Modernization  Program  replaces  two  legacy  systems  that 
have  been  in  operation  for  over  30  years,  Commodity  Command  Standard  System  and  the 
Depot  System  [16].  There  are  six  core  Working  Capital  Fund  processes  that  the  Army 
intends  to  transform,  they  are:  order  fulfillment,  demand  and  supply  planning, 
procurement,  asset  management,  materiel  maintenance,  and  financial  management. 
When  fully  deployed  in  2011,  the  LMP  program  will  be  used  by  over  17,000  users  in 
over  1,000  locations  [24]. 

The  GCSS-Army  program  integrates  the  Army’s  supply  chain  and 
replaces  1 6  stove-piped  legacy  logistics  systems  to  include  Standard  Army  Retail  Supply 
System,  Standard  Army  Maintenance  System  Enhanced,  Property  Book  Unit  Supply 
Enhanced,  and  Unit  Level  Logistics  System  -  Aviation  Enhanced  and  Standard  Army 
Ammunition  System  [20].  It  will  also  eliminate  duplicative  databases,  poor  asset 
visibility,  and  stove  piped  communications  between  the  Anny  logistics  systems  [16]. 

The  scope  of  the  GCSS-Army  program  initially  was  too  large  to  develop 
as  one  release.  It  has  been  broken  down  into  two  main  increments  with  Increment- 1 
broken  down  into  three  releases  and  Increment-2  yet  to  be  defined  [20]. 

Release  1.0  includes  Supply  Support  Activity  (SSA)  functionality 
currently  implemented  at  the  B  DSU  SSA,  Regimental  Support  Squadron,  1 1th  Annored 
Cavalry  Regiment,  Ft  Irwin,  California  [20]. 

Release  1.1  includes  Unit  Level  Supply,  Property  Book,  Maintenance 
(Aviation  and  Ground),  and  finance  (support  to  tactical  supply  and  maintenance) 
functionality  [20]. 

Release  1.2  includes  ammunition,  environmental  health  and  safety, 
finance,  and  cost  management  functionality  [20], 

Breaking  down  the  scope  of  GCSS-Army  will  make  the  development 
effort  manageable  and  allow  smaller  increments  of  capability  to  be  delivered  sooner 
rather  than  waiting  for  one  very  large  block  of  capability  to  be  delivered  later. 
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c.  Army  ERP  Costs 

The  cost  to  develop  an  ERP  system  is  difficult  to  budget  for  and  difficult 
to  keep  within  the  cost  estimate.  In  1999,  it  was  reported  that  approximately  90  percent 
of  ERP  implementations  were  late  or  over  budget  [25].  In  2003,  GCSS-Army  started  as  a 
custom  software  development  and  $95  million  was  invested  before  the  program  was 
halted.  In  2003,  the  ERP  effort  started  and  as  of  September  2006,  approximately  $203 
million  had  been  obligated.  It  is  estimated  another  $2.1  billion  will  be  invested  [16].  As 
of  2006,  the  LMP  ERP  effort  had  obligated  about  $452  million  to  develop  and  implement 
the  program  and  estimated  that  it  will  invest  at  least  another  $895  million  [16]. 

Totaling  both  LMP  and  GCSS-Army,  a  total  amount  of  over  $3.8  billion 
will  be  invested  on  the  development  of  just  these  two  ERP  systems  alone.  A  tremendous 
amount  considering  COTS  software  is  being  used. 

d.  Army  ERP  Schedules 

The  LMP  effort  started  in  1998  [16].  It  has  been  operational  since  2003, 
and  will  be  fully  deployed  in  2011.  The  program  will  operate  in  more  than  1,000 
locations  with  more  than  17,000  users  worldwide  [21].  Figure  4  shows  that  the  LMP 
program’s  Full  Operational  Capability  (FOC)  date  had  been  revised  three  times 
indicating  there  were  problems  with  the  LMP  effort.  The  revised  schedule  in  February 
2006  modified  the  FOC  to  201 1,  five  years  longer  than  the  initial  estimate  of  2006.  This 
is  typical  of  ERP  implementations  [16]. 


Figure  4.  LMP  Timeline.  From  [16] 
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The  GCSS-Army  effort  started  in  1997  as  a  custom  software  solution. 
The  commercial  ERP  effort  started  in  2003.  Figure  5  shows  that  the  GCSS-Army 
program’s  Full  Operational  Capability  (FOC)  date  has  also  been  revised  three  times 
indicating  there  were  problems  with  the  GCSS-Army  effort.  The  revised  schedule  in 
March  2006  modified  the  FOC  to  2014,  five  years  longer  than  the  initial  estimate  of  2009 
not  counting  the  custom  software  development  initial  FOC  date  [16]. 


Figure  5.  GCSS-Army  Timeline.  From  [16] 

Both  the  FMP  and  GCSS-Army  programs  had  the  FOC  event  rebaselined 
three  times.  This  change  in  Anny  ERP  schedules  is  consistent  with  the  schedule  delays 
of  the  ERP  efforts  of  the  other  DoD  Services  illustrating  that  the  length  of  ERP 
development  is  not  easy  to  detennine  and  even  harder  to  maintain. 

e.  Army  ERP  Effort  Summary 

The  Anny  is  modernizing  its  logistics  business  processes  in  order  to 

provide  asset  visibility  by  implementing  the  FMP  and  GCSS-Army  programs.  Both  of 

these  ERP  systems  will  replace  existing  legacy  systems  some  of  which  are  over  30-years 

old.  The  Army  was  missing  fundamental  documentation  such  as  the  Enterprise 

Architecture,  to  provide  the  blueprint  for  organizational  change,  and  the  CONOPS,  to 

describe  how  the  new  system  intends  to  operate.  The  functionality  of  these  ERP  systems 

includes  Supply  Support  Activity  functionality,  as  well  as  asset  visibility,  maintenance, 

finance,  and  environmental.  The  scope  for  the  GCSS-Army  program  was  broken  down 

into  manageable,  smaller  increments  in  order  to  deliver  capability  quicker  to  the  user. 

The  costs  for  the  FMP  and  GCSS-Army  programs  are  estimated  to  be  approximately 

$  1 .4B  and  $2.4B,  respectively.  Schedule  delays  have  been  realized  for  both  the  FMP  and 
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GCSS-Army  programs.  The  LMP  program  schedule  revised  the  FOC  date  by  an 
additional  five  years  from  the  original  estimate.  The  GCSS-Army  program  also  revised 
the  FOC  date  by  an  additional  five  years  from  the  original  estimate.  The  Army  ERP 
efforts  have  experienced  inadequate  documentation,  scope  redefinition,  cost  adjustments, 
and  schedule  delays,  as  shown  in  Table  1. 
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Table  1. 


Army  ERP  Summary 


Area 

Summary 

ERP  Programs 

GCSS-Army  and  LMP 

Key  Findings 

Enterprise  Architecture  and  CONOPS  not  successfully 

implemented 

Functionality 

GCSS-Armv 

Supply  Support  Activity,  Unit  Level  Supply,  Property 

Book,  Maintenance  (Aviation  and  Ground),  and 

finance  (support  to  tactical  supply  and  maintenance) 

functionality,  ammunition,  environmental  health  and 

safety,  finance,  and  cost  management  functionality. 

LMP 

Order  fulfillment,  demand  and  supply  planning, 

procurement,  asset  management,  materiel  maintenance, 

and  financial  management. 

Life  Cycle  Cost 

GCSS-Army:  $2.4B 

LMP:  $1.4B 

Schedule 

GCSS-Army:  3  slips  within  3  yrs,  FOC  slip  3  yrs,  total 

time  to  FOC  -  1 1  yrs. 

LMP:  3  slips  within  3  yrs,  FOC  slip  5  yrs,  total  time  to 

FOC  -  1 1  yrs. 
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2.  Navy  ERP  Efforts 

The  Navy  planned  to  reform  their  business  operations.  Between  1998  and  2003, 
four  different  Navy  commands  began  to  plan,  develop,  and  implement  four  ERP  pilot 
programs  [18].  These  pilot  programs  would  provide  financial  management,  supply 
management,  regional  maintenance,  and  program  management  capability  for  the  Navy. 
They  were  developed  by  four  separate  commands,  were  developed  independently,  and 
duplicated  the  same  functionality.  Despite  an  investment  of  over  $1  billion,  the  pilot 
programs  were  uncoordinated,  not  integrated,  and  were  deemed  a  failure  by  the  GAO 
[18].  The  pilot  programs  had  a  lack  of  disciplined  processes  to  include  requirements 
management  and  customized  many  areas  of  the  COTS  software  defeating  the  purpose  of 
using  out-of-the-box  functionality  [18]. 

Because  the  pilot  programs  did  not  meet  the  Navy’s  overall  requirements,  the 
Navy  decided  to  start  over  and  replace  the  pilot  programs  with  one  ERP  system  under  the 
leadership  of  a  central  program  office  [18],  The  replacement  Navy  ERP  solution 
transitions  legacy  business  processes  into  a  single  supply  solution  and  integrates  the 
functionalities  of  planning,  allowancing,  procurement,  repairables,  and  order  fulfillment 
[26].  The  Navy  ERP  program  developed  disciplined  processes  to  identify  and  manage 
program  requirements.  The  amount  of  customization  was  reduced  to  allow  only 
modifications  that  were  required  legally  or  regulatory.  Minimizing  customizations 
reduced  the  complexity  along  with  the  costs  of  development  [18].  Another  area  of  note 
was  the  realization  that  the  four  pilot  projects  used  the  implementation  method  of  their 
separate  system  integrators.  This  was  a  huge  risk  as  each  implementation  differed 
significantly  with  respect  to  the  amount  and  methodology  to  customize  the  software. 
Instead,  the  new  integrated  ERP  solution  would  implement  the  methodology  of  the  COTS 
vendor  to  the  overall  solution  to  obtain  a  more  robust  requirements  management  process. 
Requirements  can  now  be  linked  from  the  highest  level  down  to  the  COTS  transaction 
level  [18], 

The  following  paragraphs  highlight  the  difficulties  the  Navy  has  encountered  in 
developing  their  ERP  solutions  with  respect  to  GAO  key  findings,  functionality,  cost,  and 
schedule. 
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a. 


Navy  ERP  GAO  Key  Findings 


The  Navy  did  not  designate  the  four  pilot  programs  as  Major  Automated 
Information  Systems  (MAIS)  even  though  they  should  have  been  in  accordance  with 
DoD  policy  at  the  time.  Because  they  were  not  designated  MAIS  programs,  the  Navy 
never  prepared  a  mission  needs  statement  for  any  of  the  pilots  [18].  The  mission  needs 
statement  would  have  identified  the  mission  requirements  and  the  interoperability  needs. 
The  current  Navy  ERP  program  is  designated  a  MAIS  program  and  is  under  the  oversight 
of  the  OSD  and  is  required  to  adhere  to  the  OSD  acquisition  process  rules  [27].  This 
designation  has  increased  the  probability  of  success  for  the  program  by  eliminating  the 
mistakes  made  early  during  the  pilot  project  efforts. 

b.  Navy  ERP  Functionality 

The  Navy  ERP  program  is  designed  using  SAP  ERP  software.  It  will  be 
developed  and  implemented  in  three  increments. 

Increment  1.0  includes  financials,  acquisition,  billing,  budgeting,  and  cost 
planning  as  well  as  costing,  contract  awards,  and  budget  exhibits,  personnel 
administration,  training,  and  events  management  [28]. 

Increment  1.1  includes  wholesale  and  retail  supply,  supply  and  demand 
planning,  order  fulfillment,  supply  forecasting  as  well  as  retail  supply  such  as  inventory 
management,  supply  and  demand  processing  and  warehouse  management  [28]. 

Increment  1 .2  includes  Intermediate-Level  maintenance,  maintenance 
management,  quality  management,  and  calibration  management  [28], 

Increment  1.0  provides  financials  and  acquisition  capability  for  about 
36,000  users  [26].  Increment  1.1  provides  wholesale  and  retail  supply  at  the  Inventory 
Control  Point  (ICP)  and  regional  supply  centers  for  aggregate  total  of  about  75,000  users 
[26].  Increment  1.2  provides  Intermediate  (I)  level  maintenance  for  both  Maritime  and 
Aviation  for  aggregate  total  of  about  80,000  users  [26].  When  fully  implemented,  the 
program  will  support  over  86,000  users  [28]. 
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Technical  challenges  for  Navy  ERP  are  implementation  of  44  system 
interfaces  (27  Navy  specific,  17  DoD  specific),  see  Figure  6,  and  data  conversion  from 
legacy  systems  into  the  ERP  system. 
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Figure  6.  Navy  ERP  Required  System  Interfaces,  From  [18] 


Another  challenge  for  the  Navy  ERP  program  is  not  implementing  an 
IV&V  function.  The  Navy  ERP  program  uses  in-house  subject  matter  experts  and  others 
who  are  also  internal  to  the  program.  An  independent  assessor  would  be  able  to  provide 
unbiased  information  to  the  DoD  and  the  Navy  on  the  overall  status  and  effectiveness  of 
the  management  processes  [18]. 

Breaking  down  the  scope  of  Navy  ERP  will  make  the  development  effort 
manageable  and  allow  smaller  increments  of  capability  to  be  delivered  sooner  rather  than 
waiting  for  one  very  large  block  of  capability  to  be  delivered  later.  This  also  provides 
faster  payback  and  value  to  the  Navy. 
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c.  Navy  ERP  Costs 

The  Navy  ERP  program  was  rebaselined  three  times  increasing  the 
expected  life  cycle  cost  estimate  each  time.  Figure  7  shows  that  costs  increased  from  an 
estimate  of  $1,873  billion  in  2003  to  an  estimate  of  $2.44  billion  in  2007,  an  increase  of 
over  $570  million  [28].  This  is  another  example  of  how  difficult  it  is  to  estimate  an  ERP 
development  effort  and  in  this  case,  after  four  pilot  projects  had  already  failed  to  produce 
a  final  product. 

Dollars  in  billions 
13,0 


£2.44 


Fiscal  year 

SOufPQ  GAO  anjtfyiii  o t  DON  duv 

Figure  7.  Navy  ERP  Life  Cycle  Cost  Estimates.  From  [28] 
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d.  Navy  ERP  Schedule 

The  start  date  for  the  Navy  ERP  program  was  in  2003  after  the  four 
original  pilot  programs  efforts  were  stopped.  At  that  time,  original  Navy  ERP  FOC  date 
was  2011.  In  2007,  the  program  was  rebaselined  and  the  FOC  date  was  revised  to  2013, 
as  shown  in  Figure  8. 


Figure  8.  Navy  ERP  Timeline.  From  [28] 


Once  again,  here  is  an  example  of  how  difficult  it  is  to  develop  an  accurate 
forecast  for  the  ERP  development  and  implementation  schedule.  The  revision  in  the 
Navy  ERP  schedule  is  consistent  with  the  schedule  delays  of  the  ERP  efforts  of  the  other 
DoD  Services  illustrating  that  the  length  of  ERP  development  is  not  easy  to  detennine 
and  even  harder  to  maintain. 

e.  Navy  ERP  Effort  Summary 

The  Navy  is  modernizing  its  business  operations  in  order  to  provide 

financial  management,  supply  management,  regional  maintenance,  and  program 

management  capability  for  the  Navy.  The  Navy  was  initially  missing  fundamental 

documentation  such  as  the  mission  needs  statement  to  identify  mission  requirements  and 

interoperability  needs.  The  functionality  of  these  ERP  systems  includes  financials, 
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acquisition,  contracting,  wholesale  and  retail  supply  and  demand  planning,  warehouse 
management,  and  maintenance  management.  The  scope  for  the  Navy  ERP  program  was 
broken  down  into  manageable,  smaller  increments  in  order  to  deliver  capability  quicker 
to  the  user.  Technical  challenges  include  implementing  44  system  interfaces  and  data 
conversion  from  legacy  systems.  The  cost  for  the  Navy  ERP  program  is  estimated  to  be 
approximately  $2.44B,  an  increase  of  over  $570M  from  the  original  estimate.  Schedule 
delays  have  been  realized  for  the  Navy  ERP  program.  The  FOC  date  was  revised  by  an 
additional  two  years  from  the  original  estimate.  The  Navy  ERP  effort  has  experienced 
inadequate  documentation,  scope  redefinition,  cost  adjustments,  and  schedule  delays,  as 
shown  in  Table  2. 
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Table  2. 


Navy  ERP  Summary 


Area 

Summary 

ERP  Programs 

Navy  ERP 

Key  Findings 

Lack  of  MNS  in  early  pilot  programs  impacted  mission 

requirements  and  interoperability  needs,  IV&V 

function  not  implemented,  technical  challenges  in 

implementation  of  44  system  interfaces  and  data 

conversion  from  legacy  systems. 

Functionality 

Increment  1.0  includes  financials,  acquisition,  billing, 

budgeting,  and  cost  planning  as  well  as  costing, 

contract  awards,  and  budget  exhibits,  personnel 

administration,  training,  and  events  management 

Increment  1.1:  wholesale  and  retail  supply,  supply  and 

demand  planning,  order  fulfillment,  supply  forecasting 

as  well  as  retail  supply  such  as  inventory  management, 

supply  and  demand  processing  and  warehouse 

management 

Increment  1.2:  Intermediate-Level  maintenance, 

maintenance  management,  quality  management,  and 

calibration  management 

Life  Cycle  Cost 

$2.4B 

Schedule 

Rebaselined  once,  FOC  slipped  2  years,  time  to  FOC  is 

9  years 
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3. 


Air  Force  ERP  Efforts 


The  Air  Force  has  two  commercial  off-the-shelf  ERP  efforts  underway  using  the 
Oracle  E-business  suite.  They  are  the  Expeditionary  Combat  System  Support  (ECSS) 
and  the  Defense  Enterprise  Accounting  and  Management  System  (DEAMS).  They  are 
components  of  the  Air  Force  eLog21  systems  architecture  designed  to  integrate 
financials,  order  management,  purchasing,  inventory  management,  distribution,  and  other 
business  functions  of  the  Air  Force  onto  one  platform  [29].  Together  they  will  transform 
the  Air  Force's  logistics  and  financial  management  operations  and  achieve  total  asset 
visibility.  ECSS  provides  a  single  integrated  logistics  system  while  DEAMS  provides 
core  financial  management  capabilities.  ECSS  is  considered  a  key  element  in  the  Air 
Force’s  efforts  to  reengineer  and  transform  its  supply  chain  operations  from  a  reactive 
posture  to  a  more  predictive  posture  that  facilitates  greater  effectiveness  and  efficiency  in 
the  Air  Force’s  logistics  operations  that  support  the  warfighter  [17]. 

The  GAO  reported  in  2008  several  key  areas  that  the  ECSS  and  DEAMS 
programs  needed  to  improve  upon  [17].  The  GAO  stated  that  the  program’s  Risk 
Management  process  was  not  adequate  enough  to  capture  and  manage  the  program’s 
risks  well  enough  prior  to  those  risks  being  realized  within  the  program.  Program  risks 
were  managed  independently  within  the  working  level  of  the  program  however  the  risks 
were  not  visible  at  the  program  management  level  of  the  program  [17]. 

Several  potential  risk  areas  were  identified.  For  both  ECSS  and  DEAMS, 
interfaces  were  identified  and  associated  risks  were  managed  at  the  lower  program  levels, 
however  these  interface  risks  were  not  consistently  identified  at  the  program  management 
level.  Technical  challenges  that  were  not  identified  as  risk  items  include  DEAMS  having 
70  interfaces  to  implement  and  also  the  level  of  effort  involved  in  the  data  conversion 
activities.  Other  challenges  not  documented  as  risks  include  training  and  the  lack  of 
staffing  with  the  required  skill  sets  [17]. 

The  following  paragraphs  highlight  the  difficulties  the  Air  Force  has  encountered 
in  developing  their  ERP  solutions  with  respect  to  GAO  key  findings,  functionality,  cost, 
and  schedule. 
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a. 


Air  Force  ERP  GAO  Key  Findings 


The  Air  Force  strategy  to  integrate  and  govern  logistics  transformation 
initiatives  is  stated  in  the  Air  Force’s  Expeditionary  Logistics  for  the  21st  century 
(eLog21)  transformation  campaign  plan  [30].  The  ECSS  and  DEAMS  programs  when 
implemented  will  satisfy  many  eLog21  key  objectives  such  as  Air  Force-Wide  logistics 
planning,  centralized  asset  management,  total  asset  visibility,  and  predictive  maintenance 
[30].  The  eLog21  serves  as  a  guide  that  provides  a  vision  to  improve  Air  Force  logistics 
to  meet  both  the  current  and  future  threat  environments  and  serves  as  the  foundation  from 
which  program  requirements  are  derived  from. 

While  the  eLog21  strategy  provides  an  overarching  guideline  for  Air 
Force  logistics  business  process  transformation,  the  GAO  found  that  key  Air  Force 
documentation  was  not  clearly  linked  together  or  linked  to  DoD’s  Enterprise  Transition 
Plan.  Documents  such  as  the  Financial  Management  Strategic  Plan,  Accountability 
Improvement  Plan,  and  the  Logistics  Enterprise  Architecture  Concept  of  Operations  do 
not  align  to  the  DoD’s  Enterprise  Transition  Plan.  Without  this  alignment,  the  Air  Force 
will  have  a  difficult  time  achieving  DoD’s  business  transformation  priorities  and  goals 
that  include  total  asset  visibility. 

b.  Air  Force  ERP  Functionality 

ECSS  and  DEAMS  is  the  IT  solution  to  transform  its  logistics  and 
financial  management  operations  leading  to  total  asset  visibility  across  the  Air  Force. 
The  ECSS  program  provides  transportation,  supply,  maintenance  and  repair,  engineering, 
and  acquisition  functionality.  It  will  replace  250  legacy  logistics  and  procurement 
systems  and  will  support  over  250,000  Air  Force  users.  The  DEAMS  program  provides 
financial  management  and  accounting  functions  for  Air  Force  general  fund  operations.  It 
has  70  key  interfaces  and  will  replace  seven  legacy  systems  [17]. 

The  ECSS  approach  to  replacing  250  legacy  systems  in  one  development 
effort  may  be  problematic.  As  seen  with  GCSS-Army  and  Navy  ERP,  those  programs 
have  been  broken  down  into  smaller  manageable  increments  of  capability.  The  ECSS 
approach  may  take  a  longer  time  to  deliver  a  larger  block  of  capability.  The  ECSS 
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program  will  have  many  more  interfaces  to  manage,  much  more  data  conversion  of 
legacy  data  to  deal  with,  and  a  tremendous  amount  of  business  process  realignment  to 
implement  by  trying  to  replace  so  many  legacy  systems  at  one  time. 


c.  Air  Force  ERP  Costs 


The  ECSS  program  was  initiated  in  2004.  As  of  2007,  $250  million  had 
been  obligated.  The  ECSS  expected  total  life-cycle  cost  estimate  is  over  $3  billion  as 
shown  in  Figure  9.  This  estimate  may  go  higher  as  more  functionality  is  planned  to  be 
incorporated  into  ECSS  in  the  areas  of  financial  management  control  and  accountability 
[17]. 
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Figure  9.  ECSS  Funding.  From  [17] 


The  DEAMS  program  was  initiated  in  2003.  As  of  December  2007,  $119 
million  had  been  obligated.  The  DEAMS  expected  total  life-cycle  cost  estimate  is  over 
$1.1  billion,  as  shown  in  Figure  10. 
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Figure  10.  DEAMS  Funding.  From  [17] 


d.  Air  Force  ERP  Schedules 

The  ECSS  program  was  initiated  in  2004.  FOC  is  estimated  to  occur  in 
fiscal  year  2013  [17].  This  is  9  years  to  complete  design,  build,  test,  and  fielding  to  all 
units  within  the  Air  Force.  If  the  program  remains  on  schedule,  and  all  goes  well,  nine 
years  is  probably  not  too  long  a  time  frame  to  replace  250  legacy  systems.  However,  as 
other  DoD  ERP  implementations  have  shown  with  smaller  incremental  developments, 
there  are  many  challenges  to  overcome  and  with  the  scope  of  ECSS  so  large,  the 
probability  is  high  that  schedule  delays  will  occur. 

The  DEAMS  program  was  initiated  in  2003.  FOC  is  estimated  to  occur  in 
fiscal  year  2014  [17].  This  is  11  years  to  design,  build,  test,  and  field  to  all  units  within 
the  Air  Force.  With  only  seven  legacy  systems  to  replace,  this  may  be  more  realistic  that 
ECSS,  and  will  have  a  higher  probability  of  success  within  the  allotted  time  frame. 

Here  is  an  example  of  how  difficult  it  is  to  develop  an  ERP  IT  solution 
within  a  relatively  short  time  span.  With  such  long  development  times,  delays  can  be 
expected.  As  seen  with  the  ERP  efforts  of  the  other  DoD  Services  even  shorter  time 
spans  are  difficult  to  manage  and  meet. 

e.  Air  Force  ERP  Effort  Summary 

The  Air  Force  is  transforming  their  logistics  and  financial  management 
operations  in  order  to  achieve  total  asset  visibility  by  implementing  the  DEAMS  and 

ECSS  programs.  The  Air  Force  documentation  was  missing  fundamental  linkages  to  the 
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DoD’s  Enterprise  Transition  Plan  and  will  have  a  difficult  time  achieving  DoD’s  business 
transformation  priorities  and  goals.  The  functionality  of  these  ERP  systems  includes 
financial  management,  accounting,  transportation,  supply,  maintenance  and  repair, 
engineering,  and  acquisition.  The  scope  for  the  ECSS  program  is  very  large  and  plans  to 
replace  250  legacy  logistics  while  the  DEAMS  program  plans  to  replace  seven  legacy 
systems.  The  lifecycle  costs  for  the  DEAMS  and  ECSS  programs  are  estimated  to  be 
approximately  $  1 . IB  and  $3. OB  respectively.  Schedule  delays  are  likely  to  be  realized 
for  both  the  DEAMS  and  ECSS  programs.  The  DEAMS  program  schedule  is  estimated 
to  take  1 1  years  to  achieve  FOC  while  the  ECSS  program  is  estimated  to  take  nine  years 
to  achieve  FOC.  The  Air  Force  ERP  efforts  have  inadequate  linkages  to  DoD 
documentation,  very  large  scope  definition,  cost  increases,  and  potential  schedule  delays, 
as  shown  in  Table  3. 
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Table  3. 


Air  Force  ERP  Summary 


Area 

Summary 

ERP  Programs 

ECSS  and  DEAMS 

Key  Findings 

Documentation  was  not  clearly  linked  together  or 

linked  to  DoD’s  Enterprise  Transition  Plan. 

Documents  such  as  the  Financial  Management 

Strategic  Plan,  Accountability  Improvement  Plan,  and 

the  Logistics  Enterprise  Architecture  Concept  of 

Operations  do  not  align  to  the  DoD’s  Enterprise 

Transition  Plan. 

Functionality 

ECSS 

Provides  transportation,  supply,  maintenance  and 

repair,  engineering,  and  acquisition  functionality. 

Replaces  250  legacy  logistics  and  procurement 

systems. 

DEAMS 

Provides  financial  management  and  accounting 

functions  for  Air  Force  general  fund  operations.  It  has 

70  key  interfaces  and  replaces  7  legacy  systems. 

Life  Cycle  Cost 

ECSS:  $3B 

DEAMS:  $1.1B 

Schedule 

ECSS:  time  to  FOC  is  9  years 

DEAMS:  time  to  FOC  is  11  years 
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4.  Marine  Corps  ERP  Efforts 

The  GCSS-MC  program  is  the  only  ERP  effort  currently  being  developed  in  the 
Marine  Corps  and  provides  the  baseline  for  the  modernization  of  Marine  Corps  logistics 
IT  systems.  It  delivers  integrated  logistics  functionality  primarily  in  the  areas  of  supply 
and  maintenance.  It  provides  timely  and  accurate  logistics  information  and  is  accessible 
by  troops  in  garrison  or  deployed  to  austere  environments.  When  fully  implemented, 
about  33,000  users  around  the  world  will  have  access  [15]. 

a.  Marine  Corps  GAO  Key  Findings 

In  2008,  the  GAO  identified  IT  management  weaknesses  with  the  GCSS- 
MC  program.  Two  key  weaknesses  were  management  of  earned  value  and  management 
of  risks.  The  program  was  not  able  to  adequately  measure  program  progress  based  on 
actual  work  performed  therefore  program  completion  dates  could  not  be  projected 
accurately  increasing  the  likelihood  of  program  delays.  The  GAO  also  found  that  there 
were  many  risks  that  had  not  been  adequately  managed  and  that  the  mitigation  steps  for 
major  risks  either  had  not  been  implemented  or  proved  ineffective  and  this  allowed  risks 
to  become  actual  problems  and  reclassified  into  issues.  Assessing  schedule  risk  and 
allocating  schedule  reserve  to  address  these  risks  within  the  schedule  could  not  be 
adequately  measured,  and  the  GAO  believed  it  likely  that  program  completion  dates 
could  not  be  projected  [15]. 

b.  Marine  Corps  ERP  Functionality 

Per  the  GCSS-MC  ORD  and  CDD,  the  GCSS-MC  development  effort  is 
defined  as  3  major  blocks  of  capability.  These  blocks  deliver  integrated  functionality 
across  retail  and  wholesale  supply,  maintenance,  warehousing,  transportation,  finance, 
engineering,  health,  acquisition  and  manpower  systems  [10,  31].  Block  1  replaces  four 
existing  logistics  IT  systems  and  its  functionality  is  further  defined  as: 
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•  Requesting  and  tracking  the  status  of  products  (e.g.,  supplies  and 
personnel)  and  services  (e.g.,  maintenance  and  engineering); 

•  Allocating  resources  (e.g.,  inventory,  warehouse  capacity,  and  personnel) 
to  support  unit  demands  for  specific  products;  and 

•  Scheduling  maintenance  resources  (e.g.,  manpower,  equipment,  and 
supplies)  for  specific  assets,  such  as  vehicles  [15]. 

GCSS-MC  Blocks  2  and  3  are  not  yet  defined  and  are  not  planned  for 
development  until  FY12. 

c.  Marine  Corps  ERP  Costs 

Cost  for  the  GCSS-MC  Block  1  program  had  been  revised  three  times 
within  three  years.  GCSS-MC  originally  planned  to  reach  FOC  in  fiscal  year  2007  at  an 
estimated  cost  of  about  $126  million  over  a  7-year  life  cycle  [15].  This  estimate  was  later 
revised  in  2005  to  about  $249  million  over  a  13-year  life  cycle  [15].  At  the  time  of  the 
GAO  report  in  2008,  the  program  expects  to  reach  FOC  in  fiscal  year  2010  at  a  cost  of 
about  $442  million  over  a  12-year  life  cycle  [15].  Figure  11  shows  the  program’s  life 
cycle  cost  estimate  for  Block  1  against  original  and  revised  milestones. 
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Figure  11.  GCSS-MC  Program  Cost  Status.  From  [15] 

In  2010,  in  preparation  for  Milestone  C,  the  GCSS-MC  program  revised 
its  life  cycle  cost  estimate  and  submitted  a  proposed  Acquisition  Program  Baseline  that 
revised  the  life  cycle  cost  estimate  to  $1.022B  [32].  This  was  more  than  double  the 
previous  estimate  and  about  10  times  more  than  the  original  estimate  in  2003. 

d.  Marine  Corps  ERP  Schedules 

The  GCSS-MC  Block  1  program  experienced  delays  early  in  the  program, 
as  shown  in  Figure  12.  In  2004,  FOC  was  expected  in  2007,  but  the  program  was 
rebaselined  in  2006  and  moved  the  FOC  date  to  2010,  delaying  the  program  by  3  years 
[15]. 


34 


DAS  phases 

Concept 

refinement 

Technology 

development 

System  development 
and  demonstration 

(solution  design  and  build/test  activities) 

Production  and 
deployment 


2003  |  2004  | 

Fiscal  year 


|  Rebaselined 


FOC 

2005  |  2006  |  2007 


(July  28,  2008:  Issue  dale 
Of  GAO-08-822) 


FOC 

2008  |  2009  |  2010 


May  2004  schedule 
|  March  2008  schedule 


Source:  GAO  analysis  of  Manne  Corps  data 


Figure  12.  GCSS-MC  Program  Schedule  Status.  From  [15] 


The  GCSS-MC  program  would  experience  many  more  delays  at  almost 
every  key  event  in  the  acquisition  process.  Starting  with  the  2003  ORD  schedule  and 
ending  with  the  latest  schedule  that  appears  in  the  2010  Acquisition  Program  Baseline, 
the  FOC  for  the  program  was  delayed  approximately  seven  years  and  the  total  time  to 
FOC  for  the  program  was  revised  to  about  10  years.  This  schedule  delay  pattern  is 
consistent  with  the  schedule  delays  of  the  ERP  efforts  of  the  other  services.  The 
progression  of  this  schedule  delay  is  outlined  in  the  Research  Analysis  section  of  this 
thesis. 


e.  Marine  Corps  ERP  Effort  Summary 

The  GCSS-MC  program  is  the  only  ERP  effort  currently  being  developed 
in  the  Marine  Corps  and  provides  the  baseline  for  the  modernization  of  Marine  Corps 
logistics  IT  systems.  It  delivers  integrated  logistics  functionality  primarily  in  the  areas  of 
supply  and  maintenance.  The  GAO  determined  that  schedule  risk  could  not  be 
adequately  measured  and  that  it  was  likely  that  program  completion  dates  could  not  be 
projected  accurately.  An  updated  LCCE  in  2010  more  than  doubled  the  previous 
estimate  and  was  about  10  times  more  than  the  original  estimate  in  2003.  There  have 
been  many  delays  in  the  GCSS-MC  schedule.  The  FOC  for  the  program  was  delayed 
approximately  seven  years  and  the  total  time  to  FOC  for  the  program  was  revised  to 
about  10  years.  Table  4  summarizes  the  GCSS-MC  ERP  development  effort. 
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Table  4. 


GCSS-MC  ERP  Summary 


Area 

Summary 

ERP  Programs 

GCSS-MC 

Key  Findings 

Management  of  earned  value  and  risks  were 

weaknesses  and  indicative  of  a  program  unable  to  stay 

on  schedule 

Functionality 

Retail  and  wholesale  supply,  maintenance, 

warehousing,  transportation,  finance,  engineering, 

health,  acquisition  and  manpower  systems 

Fife  Cycle  Cost 

$1.022B 

Schedule 

Time  to  FOC  is  10  years,  delayed  7  years  from  original 

estimate 

C.  CHAPTER  SUMMARY 

Modernization  of  service  legacy  logistics  IT  systems  using  ERP  technology  has 
proven  to  be  a  challenge  to  keep  on  schedule  and  on  budget.  The  Army,  Navy,  Air 
Force,  and  Marine  Corps  all  have  similar  requirements  and  trying  to  implement  similar 
functionality.  Table  5  shows  a  side-by-side  comparison  of  the  four  services. 
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Table  5. 


DoD  Services  Implementation  Summary 


Army 

Navy 

Air  Force 

Marine  Corps 

GAO  Key 
Findings 

Enterprise  Arch  and 
CONOPS  not 
successfully 
implemented 

Lack  of  MNS  in 
early  pilot 
programs  impacted 
mission 

requirements  and 

interoperability 

needs 

IV&V  function  not 
implemented 

Technical 
challenges  in 
implementation  of 
44  system 
interfaces  and  data 
conversion  from 
legacy  systems 

Documentation 
was  not  clearly 
linked  together  or 
linked  to  DoD’s 
Enterprise 

Transition  Plan. 

Documents  such  as 
the  Financial 
Management 
Strategic  Plan, 
Accountability 
Improvement  Plan, 
and  the  Logistics 
Enterprise 
Architecture 

Concept  of 
Operations  do  not 
align  to  the  DoD’s 
Enterprise 

Transition  Plan. 

Weak  management 
of  earned  value 
and  risk 
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Army 

Navy 

Air  Force 

Marine  Corps 

Functionality 

GCSS-Armv 

Supply  Support 

Activity,  Unit  Level 
Supply,  Property  Book, 
Maintenance  (Aviation 
and  Ground),  and 
finance  (support  to 
tactical  supply  and 
maintenance) 
functionality, 
ammunition, 
environmental  health 
and  safety,  finance,  and 
cost  management 
functionality. 

LMP 

Order  fulfillment, 
demand  and  supply 
planning,  procurement, 
asset  management, 
materiel  maintenance, 
and  financial 
management. 

Increment  1.0 

Financials, 
acquisition,  billing, 
budgeting,  and 
cost  planning  as 
well  as  costing, 
contract  awards, 
and  budget 
exhibits,  personnel 
administration, 
training,  and 
events 

management 

Increment  1.1 

Wholesale  and 
retail  supply, 
supply  and 
demand  planning, 
order  fulfillment, 
supply  forecasting 
as  well  as  retail 
supply  such  as 
inventory 
management, 
supply  and 
demand  processing 
and  warehouse 
management 

Increment  1.2 

Intermediate-Level 

maintenance, 

maintenance 

management, 

quality 

management,  and 

calibration 

management 

ECSS 

Provides 

transportation, 

supply, 

maintenance  and 
repair, 

engineering,  and 
acquisition 
functionality. 
Replaces  250 
legacy  logistics 
and  procurement 
systems. 

DEAMS 

Provides  financial 
management  and 
accounting 
functions  for  Air 
Force  general  fund 
operations.  It  has 

70  key  interfaces 
and  replaces  7 
legacy  systems. 

Block  1 

Retail  and 
wholesale  supply, 
maintenance 

Future  Blocks 

Warehousing, 

transportation, 

finance, 

engineering, 

health,  acquisition 

and  manpower 

systems. 

Service  Cost 

$3.8B 

$2.4B 

$4.  IB 

$1.022B 

Schedule 

GCSS-Army:  3  slips 
within  3  years,  FOC 
slip  3  years,  total  time 
to  FOC  is  1  lyears. 

LMP:  3  slips  within  3 
years,  FOC  slip  5  years, 
total  time  to  FOC  is  1 1 
years. 

Rebaselined  once, 
FOC  slipped  2 
years,  time  to  FOC 
is  9  years. 

ECSS:  time  to 

FOC  is  9  years 

DEAMS:  time  to 
FOC  is  1 1  years. 

Time  to  FOC  is  10 
years,  delayed  7 
years  from  original 
estimate. 
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All  four  Services  have  exceeded  their  initial  cost  estimates  as  well  as  experienced 
delays  in  schedule.  While  this  may  not  seem  unusual  in  the  development  of  IT  systems 
in  general,  there  does  appear  to  be  a  pattern  emerging  with  ERP  systems  running  over 
cost  and  schedule. 

The  next  chapter  identifies  GCSS-MC  system  engineering  challenges  regarding 
the  technical  and  functional  requirements  and  the  complexity  of  implementing  those 
requirements.  The  complexity  of  the  development  effort  is  a  large  contributor  to  the  cost 
overruns  and  schedule  delays. 
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III.  GCSS-MC  SYSTEM  ENGINEERING  IMPLEMENTATION 

CHALLENGES 


A.  INTRODUCTION 

The  GCSS-MC  program  chose  a  COTS  ERP  product  as  the  best  alternative  to 
modernize  Marine  Corps  logistics  IT  systems  and  satisfy  the  program  requirements 
documented  in  the  GCSS-MC  ORD  and  CDD.  The  functional  and  technical 
requirements  have  remained  constant  over  the  life  of  the  program  and  the  requirements 
are  traceable  between  the  documents.  As  the  program  progressed  through  the  design, 
build  and  test  phases,  implementation  of  those  requirements  was  not  as  easy  as  originally 
thought.  The  program  was  unable  to  achieve  a  MS  B  decision  five  years  after 
achievement  of  MS  A  thus  breaching  and  forcing  a  rebaseline  of  the  program.  This 
chapter  discusses  the  reasons  for  choosing  a  COTS  product,  requirements  documentation, 
the  functional  and  technical  requirements,  and  the  customization  of  the  ERP  software 
needed  to  meet  the  Marine  Corps  required  functionality.  It  is  the  ambiguity  of  the 
program  requirements  and  the  complexity  of  implementing  those  requirements  that 
causes  the  program  to  run  over  cost  and  schedule. 

B.  ANALYSIS  OF  ALTERNATIVES 

In  May  2004,  the  GCSS-MC  Program  Office  performed  an  Analysis  of 
Alternatives  to  determine  the  appropriate  material  solution  that  would  meet  the 
requirements  defined  in  the  September  2003  GCSS-MC  ORD.  The  five  alternative 
solutions  of  Status  Quo,  Upgrade  Legacy,  Custom  Implementation,  COTS,  and 
Outsource  were  narrowed  down  to  three  for  evaluation.  The  results  shown  in  Table  6 
lead  the  Program  Office  to  choose  a  COTS  solution  as  it  met  the  most  intended  scope  of 
the  system  and  had  the  highest  return  on  investment  [33]. 
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Table  6 


AOA  Results  Summary.  From  [33] 


Area  of  Analysis 

Alternative  1 

Alternative  3 

Alternative  4 

Status  Quo 

Custom 

COTS 

Risk  (1-100) 

79 

43 

51 

Functional  Requirements  (1-500) 

178 

339 

391 

Non-Functional  Requirements  (1- 
500) 

141 

307 

349 

ROI 

0 

6.33 

17.28 

Additional  Discriminators 

Estimated  Cost  (Rank) 

1 

3 

2 

Breakeven  (w/Benefits) 

3  (Infinite) 

2  (2010) 

1  (2008) 

Discriminator  Total 

4 

5 

3 

The  AOA  analysis  results  in  Figure  13  give  a  direct  comparison  of  the  data  and 
clearly  show  the  COTS  solution  as  the  desired  implementation  of  choice. 


AoA  Summary 


O  Status  Quo 
•  Custom 
OCOTS 


Figure  13  GCSS-MC  AOA  Analysis  Results.  From  [33] 

With  the  COTS  ERP  material  solution  chosen,  the  Marine  Corps  developed 
requirements  and  codified  them  in  the  May  2005  GCSS-MC  CDD.  The  CDD 
requirements  were  used  as  a  baseline  for  defining  program  cost,  schedule,  and 
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performance.  A  COTS  implementation  was  believed  to  provide  several  economic 
benefits  and  avoid  pitfalls  associated  with  the  conversion  of  legacy  systems  to  a  modem 
architecture.  With  fewer  errors  in  legacy  data  conversion,  problems  of  being  over 
budget,  behind  schedule,  and  technologically  inefficient  would  be  avoided  [33]. 
However,  as  shown  later  in  this  chapter,  the  Program  Office  would  face  challenges  not 
only  in  meeting  a  defined  schedule  but  in  the  planning  of  a  realistic  schedule  that  would 
meet  acquisition  guidelines  contrary  to  the  conclusions  in  the  AOA. 

C.  REQUIREMENTS  DOCUMENTATION 

The  GCSS-MC  program  has  well  documented  requirements  that  have  remained 
stable  throughout  its  development.  While  the  program  has  had  its  difficulties  in 
maintaining  cost  and  schedule,  the  core  requirements  never  changed.  Many  programs 
suffer  from  requirements  creep  but  the  GCSS-MC  program  has  stayed  true  to  its  root 
requirements. 

The  1997  Mission  Need  Statement  (MNS)  defined  a  need  to  modernize  the 
Marine  Corps  logistics  and  Combat  Service  Support  (CSS)  information  technology 
capabilities  and  to  eliminate  “stove-piped”  development  of  information  technology 
systems  [10].  The  MNS  established  the  foundation  for  all  future  GCSS-MC  requirements 
development. 

In  2000,  the  GCSS-MC  Mission  Area  (MA)  Initial  Capabilities  Document  (ICD) 
was  approved  and  defined  Combatant  Command  logistical  area  functions  required  for 
execution  by  the  MAGTF.  In  2003,  the  GCSS-MC  Operational  Requirements  Document 
(ORD)  established  the  capabilities  for  GCSS-MC  Logistics  Chain  Management  (LCM) 
and  provided  the  information  technology  capabilities  necessary  to  execute  MAGTF  CSS 
functions  in  expeditionary,  joint,  and  combined  environments. 

The  ORD  defined  three  major  blocks  of  capability  and,  in  December  2003,  a 
System  Subsystem  Specification  (SSS)  was  developed  to  translate  those  high  level  blocks 
of  capability  into  lower  level  functional  and  technical  requirements  for  all  three  blocks. 
The  GCSS-MC/LCM  program  received  Milestone  A  approval  for  the  first  block  of 
capability  on  23  July  2004  from  the  Milestone  Decision  Authority,  the  Assistant 
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Secretary  of  Defense,  Networks  and  Information  Integration.  In  May  2005,  a  Capability 
Development  Document  (CDD)  was  created  to  establish  requirements  for  the  first  block 
of  capability  [10].  The  CDD  requirements  are  broken  down  into  business  process 
subsystem  requirements  that  are  translated  to  component  level  requirements.  The  GCSS- 
MC  requirements  documentation  tree  is  shown  in  Figure  14. 


Figure  14.  GCSS-MC  Requirements  Documentation  Tree 


The  GCSS-MC  program  follows  the  traditional  “V-Model”  for  development  and 
testing  of  requirements.  Requirements  are  defined,  categorized,  and  traced  in  detail  from 
business  requirements  to  component  requirements  as  shown  in  Figure  15  [34]. 
Component  requirements  consist  of  Reports,  Interfaces,  Conversions,  Extensions  (RICE) 
objects  that  constitute  the  customization  of  the  ERP  software  to  perfonn  the  Marine 
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Corps  logistics  business  operations.  It  is  the  development  of  the  RICE  objects  that  define 
the  complexity  of  the  ERP  design,  as  shown  later  in  this  thesis. 
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Figure  15.  GCSS-MC  "V-Model".  From  [34] 


All  requirements  are  captured  in  a  traceability  tool  from  IBM  called  Rational 
DOORS®.  The  Functional  Baseline  consists  of  configuration  and  business  procedure 
documents  traceable  to  a  TE.040  test  document.  The  Technical  Baseline  consists  of 
system  and  sub-system  architecture  and  management  documents  traceable  to  a  TE.054 
test  document.  And  the  RICE  baseline,  derived  from  configuration  documents,  is 
traceable  to  a  TE.050  test  document.  The  GCSS-MC  program  has  a  well  established 
requirements  baseline  along  with  a  solid  traceability  effort,  as  shown  in  Figure  16  [34]. 


Figure  16.  GCSS-MC  Traceability.  From  [34] 
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GCSS-MC  is  built  upon  a  COTS  ERP  solution  that  delivers  integrated 
functionality  across  retail  and  wholesale  supply,  maintenance,  warehousing, 
transportation,  finance,  engineering,  health,  acquisition  and  manpower  systems  [10]. 
Accomplishing  the  development  of  all  of  these  capabilities  in  a  single  effort  is  very  large 
and  would  take  several  years  to  accomplish.  The  COTS  ERP  software  is  designed  with 
flexibility  such  that  increments  of  capability  can  be  developed  and  implemented  in  an 
individual  fashion.  The  GCSS-MC  program  office  took  advantage  of  this  flexibility  and 
divided  the  development  effort  into  three  major  blocks  of  functional  capability  shown  in 
Table  7: 

Table  7.  GCSS-MC  Block  Definition.  After  [31] 


Block 

Capability 

Block  1 

Retail  Supply  and 

Maintenance.  Deployed 

environment  using 

SIPRNET  and  NIPRNET. 

Block  2 

Wholesale  Inventory 

Management,  Depot 

Operations,  Warehousing, 

Transportation,  Enhance 

Order  and  Inventory  Mgmt. 

Block  3 

Advanced  Logistics 

Planning,  Engineering, 

Medical. 

These  three  blocks  provide  the  Marine  Corps  with  total  Logistics  Chain 
Management  of  all  commodities.  The  functional  and  technical  non-functional 
requirements  discussed  in  Section  D  provide  the  baseline  capability  required  by  the  ERP 
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system.  It  is  the  uniqueness  of  these  requirements  that  causes  the  ERP  out-of-the-box 
software  to  be  customized  with  the  development  of  RICE  objects.  Section  D  discusses 
the  complexity  of  implementing  the  RICE  objects  and  that  proves  to  be  a  large  challenge 
for  the  GCSS-MC  System  Engineering  team. 

D.  REQUIREMENTS 

The  requirements  for  the  GCSS-MC  program  are  represented  by  two  main 
categories,  Functional  and  Technical/Non-Functional.  The  main  purpose  of  GCSS-MC  is 
to  provide  the  basic  logistics  functions  of  logistics  chain  management,  specifically,  the 
ability  to  order  and  track  supplies  and  the  ability  to  schedule  and  track  maintenance.  The 
ERP  software  can  perform  those  basic  functions  out-of-the-box.  There  are,  however, 
other  requirements  that  are  levied  upon  a  DoD  ERP  implementation  that  make  the 
development  effort  complex.  They  are  described  below  in  terms  of  the  documented 
GCSS-MC  functional  and  technical  requirements. 

1.  Functional  Requirements 

The  GCSS-MC  functional  requirements  are  defined  by  four  categories: 

•  Top  Level  Capabilities 

•  Joint  Financial  Management  Improvement  Program  (JFMIP) 

•  Standard  Financial  Information  Structure  (SFIS) 

•  Resource  Financial  Accounting  (RFA). 

The  Top  Level  Capabilities  provide  the  baseline  functional  requirements 
necessary  for  the  system  to  perform  logistics  operations  and  are  established  in  1 1 
functional  areas  defined  by  the  GCSS-MC  CDD  [10].  These  functional  areas  include  the 
basic  logistics  functions  of  Inventory  Planning,  Demand  Planning,  Mission  Planning, 
Maintenance  Management  and  Planning,  Asset  Management,  Inventory  Management, 
Service  Management,  Financial  Resource  Management,  Warehouse  Management, 
Reporting  System  Management,  and  System  Management.  The  ERP  software  is  very 
capable  of  providing  this  basic  functionality.  The  Marine  Corps  had  an  existing  logistics 
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chain  management  process  in  place,  however,  and  the  ERP  software  had  to  be  modified 
to  exercise  that  process.  Other  complexities  are  introduced  when  DoD  financial 
requirements  (JFMIP,  SFIS,  and  RFA)  are  placed  on  the  program. 

The  JFMIP  requirements  define  the  financial  management  practices  in 
government.  Specifically  it  is  “...  a  joint  and  cooperative  undertaking  of  the  U.S. 
Department  of  the  Treasury  the  General  Accounting  Office,  the  Office  of  Management 
and  Budget,  and  the  Office  of  Personnel  Management,  working  in  cooperation  with  each 
other  and  other  agencies  to  improve  financial  management  practices  in  government”  [35]. 
The  JFMIP  guides  financial  management  improvement  across  government  and  explains 
Federal  needs  by  providing  agencies  infonnation  to  improve  their  financial  systems. 

The  SFIS  requirements  standardize  financial  reporting  across  DoD  by  ensuring  a 
comprehensive  "common  business  language"  is  used  for  budgeting,  financial  accounting, 
cost/perfonnance  management,  and  external  reporting  across  the  DoD  enterprise  [36]. 
The  intent  of  SFIS  is  to  standardize  financial  reporting  across  DoD  and  reduce  the  cost  of 
auditing.  To  be  compliant  means  the  ERP  program  must  implement  the  SFIS  business 
rules  and  values  in  the  Business  Enterprise  Architecture.  There  are  7 1  data  elements  in 
SFIS  and  they  all  have  specific  business  rules  that  address  syntax,  usage  and  relationships 
[36].  The  SFIS  requirements  are  not  part  of  the  ERP  out-of-the-box  baseline  and  require 
customization  of  the  ERP  software,  an  unexpected  part  of  the  design  effort  for  GCSS- 
MC. 

The  RFA  requirements  ensure  that  IT  systems  comply  with  regulatory  financial 
policies  and  procedures  [37].  Once  again,  not  part  of  a  nonnal  ERP  out-of-the-box 
baseline  and  cause  for  additional  customization  of  the  ERP  software. 

The  total  number  of  Functional  Requirements  derived  from  these  four  functional 
categories  is  shown  in  Table  8. 
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Table  8. 


GCSS-MC  Functional  Requirement  Count.  After  [34] 


Requirement  Type 

Total 

Top-level  Capability 

681 

JFMIP 

315 

SFIS 

36 

RFA 

53 

Total 

1,085 

These  1,085  requirements  represent  the  functional  capability  required  to  be 
provided  by  the  ERP  system  for  GCSS-MC  to  perfonn  the  core  capability  of  supply  and 
maintenance  logistics  chain  management.  Once  these  functional  requirements  are 
designed,  built,  tested,  and  operational,  the  foundation  is  set  for  incorporation  of  other 
capabilities.  It  is  the  uniqueness  of  these  functional  requirements  that  requires 
customization  of  the  ERP  software.  Any  modification  to  the  baseline  ERP  software 
means  additional  development  time  is  required  and  is  an  opportunity  to  introduce 
complexity  and  error  in  the  development  phase  of  the  project. 

2.  Technical  /  Non-Functional  Requirements 

GCSS-MC  is  comprised  of  several  key  technical  components  consisting  of  data 
capture  using  AIT  and  the  use  of  a  shared  data  environment  accessible  via  the  World 
Wide  Web.  The  Joint  Technical  Architecture  (JTA)  framework  that  defines  operational, 
system,  and  technical  architecture  views  is  used  to  describe  and  define  the  GCSS-MC 
system  [31]. 

GCSS-MC  technical  requirements  are  defined  by  five  categories: 

•  Technical 

•  Joint  Data  Element  (JDE)  Reporting 

•  Information  Assurance  (IA) 
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•  Net  Ready  (NR)  Key  Performance  Parameter  (KPP) 

•  Visibility  KPP 

Technical  requirements  are  those  requirements  that  describe  technically  how  the 
system  is  to  operate.  The  system  must  have  the  ability  to  be  accessed  from  both  a 
garrison  and  deployed  environment  and  must  be  able  to  synchronize  data  between  the 
two  environments.  Data  rates  must  be  in  accordance  with  agreed  upon  interface  controls 
and  continuity  of  operation  must  be  in  place  to  ensure  continuous  access  to  the  system. 
The  requirement  to  access  the  system  from  a  deployed  environment  is  very  unique  to  the 
DoD  since  troops  are  always  on  the  move,  within  an  austere  environment,  with  normally 
a  poor  communications  infrastructure.  This  is  not  normally  built  into  a  COTS  piece  of 
software  and  requires  an  extensive  research  and  architecture  design  effort  to  properly 
customize  the  ERP  software. 

JDE  reporting  requirements  are  specific  data  elements  required  to  be  provided  to 
the  GCSS-Joint  program.  Visibility  and  location  of  equipment  within  a  theater  are 
required  to  be  seen  by  Joint  forces.  Availability  and  accessibility  of  Marine  Corps 
prepositioned  assets  must  also  be  visible  to  Joint  forces.  The  JDE  requirements  add 
additional  data  fields  to  the  baseline  COTS  software  and  require  additional  interfaces  to 
pass  that  data  forward.  This  extensive  modification  to  and  configuration  of  the  COTS 
software  introduces  complexity  into  the  system  design. 

Information  assurance  requirements  are  very  extensive  due  to  vulnerabilities  from 
technology  threats  and  must  be  applied  throughout  the  system  life  cycle.  I A  requirements 
represent  the  majority  of  the  GCSS-MC  technical/non-functional  requirements.  They 
must  be  in  accordance  with  DoD  IA  and  acquisition  policies  and  regulations  in  order  to 
protect  the  mission  data  [31]. 

There  are  two  GCSS-MC  Key  Performance  Parameters.  The  first  is  the  Net 
Ready  KPP.  This  states  that  data-sharing  of  Net-Centric  Operations,  Warfare  Reference 
Model,  and  GIG  Key  Interface  Profiles  will  be  satisfied  to  the  requirements  of  specified 
Joint  integrated  architecture  products  and  infonnation  assurance  accreditation  [13].  The 
second  is  the  visibility  KPP.  When  connected  to  GCSS-MC  LCM  Deployed  or 
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Enterprise  instances,  transactions  are  visible  to  authorized  users  after  entry  by  its 
originator  within  60  minutes  95%  of  the  time  [13].  These  two  KPPs  bring  into  play  the 
Joint  aspect  of  data  sharing  and  technically  the  ability  to  view  transactions  that  are 
dependent  on  the  architecture  of  the  network.  Both  KPPs  require  customization  of  the 
COTS  software  and  increase  the  development  effort  of  the  ERP  software. 

The  total  number  of  Technical  Non-Functional  Requirements  is  shown  in  Table  9. 
These  290  Technical  Non-Functional  requirements  represent  the  physical  and  logical 
architecture  required  to  meet  the  intent  of  the  GCSS-MC  ORD.  These  requirements 
provide  an  operational  architecture  that  enables  the  functional  requirements  to  provide 
the  deployed  warfighter  the  ability  to  request  and  track  the  status  of  supplies  and  services 
in  an  austere  environment. 

Table  9.  GCSS-MC  Technical  Non-Functional  Requirement  Count.  After  [34] 


Requirement  Type 

Total 

Top-level  Capability 

129 

JDE  Reporting 

23 

Infonnation  Assurance 

133 

NR  KPP 

3 

Visibility  KPP 

2 

Total 

290 

The  Marine  Corps  requirement  to  deploy,  move,  and  stand-up  capability  in  an 
austere  environment  is  not  typical  for  a  public  company  in  industry  and  proves  to  be  the 
biggest  challenge  in  this  ERP  software  development.  Hence  significant  customization  is 
required. 
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E.  CUSTOMIZATION  (RICE) 

COTS  software  by  definition  is  usage  of  the  software,  as  is,  bought  straight  off  the 
shelf.  There  are  two  approaches  an  organization  can  take  when  implementing  COTS 
software,  minimal  customization  of  the  software  that  requires  a  potential  change  in 
organizational  business  processes,  and  extensive  customization  of  the  software  to  mimic 
the  organizations  existing  business  processes. 

The  minimal  customization  approach  would  save  much  time  and  effort  in  the 
design  and  development  phase  and  would  ensure  compatibility  of  future  version  upgrades 
of  the  software.  However,  this  is  a  very  large  change  management  effort  and  users  have 
to  be  retrained  in  the  new  business  processes  required  to  operate  the  new  software. 

The  extensive  customization  approach  is  to  have  the  software  mimic  the 
organizations  existing  business  processes.  This  extensive  customization  requires  a  large 
software  development  effort  that  could  take  a  long  time  to  implement  and  makes  future 
upgrades  challenging  and  technically  more  difficult  [38].  This  is  the  approach  of  the 
GCSS-MC  program. 

The  extensive  customization  approach  requires  modification  of  the  ERP  software 
by  developing  unique  Reports,  Interfaces,  Conversions,  and  Extensions  commonly 
referred  to  as  RICE  objects.  RICE  objects  can  be  complex  and  a  large  number  of  RICE 
objects  can  make  the  ERP  implementation  very  difficult  and  time  consuming. 

Reports  are  outputs  from  the  ERP  software  that  provide  information  about  the 
data  that  has  been  entered  [39].  Many  existing  reports  may  be  used  within  the  new  ERP 
software  but  new  reports  may  need  to  be  created  if  unique  data  fields  have  been  utilized 
or  reports  from  legacy  systems  need  to  be  recreated.  Existing  legacy  reports  need  to  be 
cataloged  and  analyzed  to  determine  if  that  report  is  still  needed  in  the  ERP.  The  ERP 
may  offer  a  better  way  to  output  data  and  legacy  reports  may  not  be  necessary  to  create. 
Legacy  reports  should  also  be  prioritized  so  that  the  focus  of  the  initial  ERP 
implementation  is  on  the  essential  reports  and  not  the  nice-to-have  reports. 

Interfaces  may  be  required  to  link  external  systems  to  the  ERP  software.  An 
interface  can  be  as  simple  as  data  exported  from  the  external  system  and  imported  into 
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the  ERP  system.  An  interface  can  also  be  very  complex  if  the  data  movement  needs  to  be 
synchronized  between  the  two  systems  [39].  The  more  interfaces,  the  more  technically 
challenging  the  ERP  software  development  and  the  more  complex  the  ERP  development 
and  maintenance.  Interfaces  can  also  be  troublesome  since  the  ERP  system  has  no 
control  over  any  interface  modifications  performed  on  the  other  end.  A  rigorous 
configuration  management  process  needs  to  be  in  place  to  ensure  all  changes  to  either  end 
of  the  interface  do  not  cause  adverse  effects  on  either  system. 

Conversions  are  a  deceiving  area  of  implementation  and  one  of  the  most  costly 
areas  of  implementation  [39].  Data  clean  up  is  a  costly  area  of  implementations  in  terms 
of  labor,  the  more  records  the  more  time  consuming  [39].  Does  the  ERP  software  have 
all  the  required  data  fields?  Does  the  legacy  data  to  be  transferred  confonn  to  the  ERP 
standard  data  format?  A  standard  data  import  template  can  be  used  to  map  data  fields  to 
and  ensures  a  consistent,  repeatable  process  to  move  data  from  the  legacy  system.  If  the 
data  to  be  moved  is  from  a  very  old  system,  it  needs  to  be  parsed  and  corrected  and  that 
can  be  very  time  consuming  [39]. 

Extensions  provide  additional  functionality  that  does  not  exist  in  the  ERP 
software.  Often  functionality  required  from  the  old  system  does  not  exist  in  the  ERP 
software  and  is  needed  to  perform  a  very  specific  task.  In  these  cases,  a  separate  program 
must  be  developed  using  the  tools  contained  in  the  ERP  system  and  data  hooks  are 
created  to  link  the  extension  to  the  core  ERP  [39].  Extensions  should  be  avoided  if 
possible  [39].  GCSS-MC  has  36  extensions  in  the  Block  1  release  which  seems  to  be 
high  since  extensions  of  any  kind  should  be  avoided. 

Reports,  Interfaces,  Conversions,  and  Extensions  are  important  and  necessary  in 
ERP  implementations  and  need  to  be  scoped  early  in  the  initial  planning  phase. 
Insufficient  time  in  the  schedule  or  lack  of  resources  can  have  a  detrimental  impact  on  the 
overall  implementation  budget  [39]. 

The  GCSS-MC  Program  Office  selected  the  Oracle  1  li  E-Business  Suite  as  the  IT 
solution  for  modernizing  the  Marine  Corps  Logistics  IT  Systems.  The  Oracle  product 
was  selected  in  part  because  it  is  COTS  and  comes  with  an  integrated  suite  of  capability 
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that  the  Marine  Corps  thought  could  be  used  without  much  modification.  However,  as 
seen  in  this  chapter,  a  COTS  product  does  not  satisfy  the  functional  and  technical 
requirements  of  the  Marine  Corps  out  of  the  box  and  requires  much  customization  in  the 
form  of  RICE  objects.  The  RICE  objects  can  be  very  complex  given  that  the  Oracle 
COTS  product  was  designed  for  best  commercial  practices  in  the  public  sector  instead  of 
for  the  very  specific  Marine  Corps  business  processes  currently  in  place,  some  of  which 
have  been  used  over  the  past  30  years  with  their  existing  IT  systems. 

One  of  the  first  efforts  the  Program  Office  performed  was  a  fit-gap  analysis.  This 
effort  consisted  of  comparing  the  GCSS-MC  requirements  against  the  capabilities  of  the 
Oracle  ERP  software.  If  the  Oracle  ERP  software  could  not  perform  the  function 
required  by  the  Marine  Corps  requirement,  it  was  called  a  gap  and  the  software  would  be 
modified  to  meet  the  requirement  with  a  Report,  Interface,  Conversion,  or  Extension 
object.  Throughout  the  development  cycle  of  the  GCSS-MC  program,  requirements  were 
continuously  reviewed  and  software  design  closely  monitored  to  ensure  all  requirements 
were  being  met.  During  the  operational  analysis  (OA)  phase  of  the  program,  a  total  of 
1,237  requirements  were  identified.  Approximately  90%  of  them  were  deemed  to  be  a 
“fit”  leaving  the  rest  to  be  “gaps”  implemented  using  a  RICE  object.  Table  10  breaks 
down  the  fit-gap  percentages  of  the  requirements. 

Table  10.  OA  Phase  Fit-gap  Requirements 


#  Requirements 

#  Fit 

#  Gap 

%  Fit 

Request  Management 

158 

137 

21 

87% 

Supply 

515 

482 

33 

94% 

Maintenance 

216 

183 

33 

85% 

F  inance 

189 

165 

24 

87% 

System  Admin 

159 

146 

13 

92% 

Total 

1237 

1113 

124 

90% 

As  the  program  progressed,  the  number  of  requirements  was  refined  and  the 
Fit/Gap  percentage  evolved  as  shown  in  Figure  17  [40].  It  is  interesting  to  note  that  there 
is  an  83%  fit  of  the  GCSS-MC  requirements  to  the  COTS  out-of-the-box  software.  That 
may  appear  to  be  a  very  good  fit  but  it’s  not  only  the  number  of  RICE  objects  that 
determine  the  size  of  the  design  effort  but  the  complexity  of  the  customization  required. 
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Fit/Gap  Analysis 
(FUE/IOT&E 
Implementation  Phase) 
7  Oct  2009 


Rqmts 

959 

Fit 

794 

Gap 

165 

Fit  % 

83% 

RICE 

101 

Figure  17.  Fit/Gap  Analysis 


With  only  an  83%  fit  of  the  requirements  to  the  ERP  software  capability, 
development  and  implementation  of  the  RICE  objects  was  critical  to  the  success  of  the 
GCSS-MC  effort.  Almost  20%  of  the  GCSS-MC  requirements  required  RICE  objects 
and  this  meant  a  more  complex  design  and  implementation.  It  was  this  complex  design 
that  drove  the  project  cost  overruns  and  schedule  delays.  The  Program  Office  recognized 
the  complexity  and  decided  to  design  and  implement  the  Block  1  effort  in  two  releases  as 
shown  in  Figure  18  [41]. 


Figure  18.  GCSS-MC  Two  Release  Strategy.  From  [41] 


55 


The  two  release  strategy  allowed  the  Program  Office  to  field  the  baseline  functional 
capability  and  get  the  system  to  users  quicker  while  continuing  to  develop  the  much  more 
difficult  technical  aspects  of  deployment  with  a  multiple  instance  architecture 
incorporating  the  data  synchronization  and  SIPRNET  capability.  Table  11  shows  the 
allocation  of  RICE  objects  between  the  two  releases.  The  more  technically  challenging 
Data  Synchronization  and  Cross  Domain  Solution  were  moved  into  Release  1 .2  allowing 
the  baseline  functionality  of  Reports,  Interfaces,  Conversions,  and  Extensions  to  be 
developed  in  a  timely  manner. 

Table  11.  RICE  Allocation 


RICE  Type 

Release  1.1 

Release  1.2 

Cross  Domain  Solution 

0 

8 

Data  Synchronization 

1 

34 

Reports 

18 

1 

Interfaces 

29 

13 

Conversions 

17 

1 

Extensions 

35 

1 

Total 

100 

58 

With  the  technically  challenging  RICE  objects  of  cross  domain  solution  and  data 
synchronization  moved  into  Release  1.2,  the  GCSS-MC  program  can  field  the  basic 
capability  of  supply  and  maintenance  management  sooner  to  the  war  fighter  and  speed  up 
the  process  of  eliminating  the  legacy  supply  and  maintenance  systems. 

F.  GCSS-MC  SCHEDULE  HISTORY 

The  GCSS-MC  program  projected  a  delay  in  schedule  with  almost  every 
acquisition  document  produced  or  at  each  milestone  event.  Each  new  schedule  produced 
reinforces  the  fact  that  the  initial  or  previous  schedule  was  unrealistic.  This  can  be  due  to 
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many  factors  such  as  expectations  from  the  Marine  Corps  to  hold  fast  to  desired  dates  and 
the  program  office’s  day  to  day  challenges  of  implementing  an  ERP  system.  The 
following  sections  describe  the  chronological  events  and  corresponding  acquisition 
documents  that  represent  the  important  milestone  dates  at  that  time.  A  trend  emerges  as 
the  milestone  dates  change  constantly  ultimately  causing  a  breach  in  program  schedule 
and  forcing  the  program  to  rebaseline. 

1.  Pre-Milestone  A 

According  to  the  GCSS-MC  ORD  dated  September  2003,  the  IOC  for  GCSS-MC 
will  be  at  the  end  of  fiscal  year  2004  and  the  FOC  for  GCSS-MC  will  be  during  FY-2006 
[31].  The  plan  is  to  field  GCSS-MC  to  35,000  users  at  three  Marine  Corps  bases,  several 
supporting  establishments,  and  in-theater  locations  around  the  world.  In  September  2003, 
when  the  ORD  was  written,  the  CDD  requirements  had  not  been  written.  The  scope  was 
defined  at  a  very  high  level  within  the  ORD  and  the  material  solution  had  not  been 
selected.  Milestones  had  not  been  defined,  only  an  IOC  and  FOC  had  been  determined  as 
shown  in  Figure  19.  In  order  to  meet  an  IOC  in  the  fourth  quarter  of  FY2004,  much  work 
had  to  be  done  from  development  of  requirements  and  architecture,  to  build  and  test,  to 
train  and  field.  That  is  much  to  accomplish  in  only  a  one  year  period  from  ORD 
requirements  to  a  users  hands-on-keyboard. 


ORD  SCHEDULE  (Sep  2003) 
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No  Change  from  Previous  Schedule 

Change  from  Previous  Schedule 

Figure  19.  GCSS-MC  ORD  Schedule 


The  2004  Acquisition  Strategy/Acquisition  Plan  (AS/AP)  defined  a  program 
strategy  to  first  select  a  COTS  vendor  and  then  acquire  a  systems  integrator  [42].  The 
program  office  chose  the  Oracle  lli  E-Business  Suite  as  its  COTS  material  solution  and 
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selected  a  systems  integrator.  A  fit-gap  analysis  was  performed  to  see  how  well  the 
Oracle  software  satisfied  the  documented  program  requirements. 

The  program  office  defined  milestone  events  along  with  a  Design  Readiness 
Review  (DRR)  and  Full  Rate  Production  (FRP)  review.  Figure  20  shows  that  IOC  was 
delayed  two  years  and  FOC  was  delayed  one  quarter.  It  is  remarkable  that  the  program 
thought  it  could  achieve  FOC  only  three  to  six  months  after  IOC  considering  fielding  is 
to  be  to  approximately  35,000  users  [31].  Note  that  there  is  only  one  year  between  the 
MS  A  and  MS  B  events.  That  means  requirements  must  be  established,  contracts  put  in 
place,  fit/gap  analysis  performed,  architecture  developed,  system  designed  built  and 
tested,  and  users  trained  and  fielded  to  all  within  one  year.  That  is  very  aggressive. 


AS/AP  SCHEDULE  (May  2004) 
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Figure  20.  GCSS-MC  2004  AS/AP  Schedule 


2.  Milestone  A  Achieved 

The  GCSS-MC  program  achieved  MS  A  in  July  2004.  With  the  Oracle  lli 
E-Business  suite  selected  as  the  material  solution,  a  systems  integrator  selected,  and 
program  requirements  defined  in  a  CDD,  a  fit/gap  analysis  was  performed.  The  program 
schedule  shown  in  Figure  21  depicts  a  one  quarter  delay  in  the  MS  B  decision  but  all 
other  dates  holding  true  to  the  previous  AS/AP  schedule.  Overall,  not  much  of  a  delay 
considering  the  program  had  advanced  one  full  year.  Still  ambitious  to  think  FOC 
follows  IOC  by  only  three  to  six  months. 
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CDD  SCHEDULE  (May  2005) 
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Figure  21.  GCSS-MC  CDD  Schedule 


In  January  2006,  the  GCSS-MC  program  terminated  the  contract  it  had  with  its 
systems  integrator  and  in  February  2006,  the  program  selected  a  different  company  to  be 
the  new  system  integrator  to  determine  the  high-level  architectural,  technological,  and 
configuration  requirements  to  support  the  functional  and  information  needs  of  the  system 
[42].  This  shift  in  systems  integrators  caused  a  new  approach  to  system  design  using  the 
new  system  integrators  software  development  methodology.  A  fit/gap  Analysis,  RICE 
object  list,  and  a  Conceptual  Architecture  were  developed  and  technical  challenges  arose 
[42].  A  combination  of  switching  to  a  new  systems  integrator  and  the  discovery  of  the 
technical  challenges  caused  delays  in  the  program  and  a  new  schedule  was  developed  and 
reflected  in  the  November  2006  AS/AP  shown  in  Figure  22.  MS  B,  MS  C,  and  IOC  were 
delayed  by  about  two  years  and  FOC  was  delayed  by  about  two  and  a  half  years.  Note 
that  more  time  was  inserted  between  IOC  and  FOC,  about  nine  months,  but  even  that 
added  time  would  prove  to  be  a  bad  estimate  as  shown  later  in  this  thesis. 
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Figure  22.  GCSS-MC  November  2006  AS/AP 
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The  March  2007  System  Engineering  Plan  did  not  refer  to  milestones  or 
IOC/FOC  dates  so  the  indication  is  that  they  remained  the  same  as  the  dates  in  the  2006 
AS/AP.  Figure  23  shows  no  delays  since  the  AS/AP  schedule  from  five  months  back. 
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Figure  23.  GCSS-MC  2007  System  Engineering  Plan 


3.  Milestone  B  Achieved 

MS  B  was  achieved  in  April  2007  only  one  month  after  the  expected  date  stated 
in  the  AS/AP.  The  schedule  was  revised  at  MS  B,  MS  C  and  FOC  were  delayed  by  about 
six  months  and  IOC  by  three  months.  However  the  program  was  still  on  track  to  achieve 
IOC  within  five  years  of  MS  A.  Objective  and  Threshold  values  were  introduced  for  the 
first  time  in  the  APB,  objective  dates  are  shown  in  Figure  24. 
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Figure  24.  GCSS-MC  MS  B  APB  Schedule 


The  GCSS-MC  program  is  an  AC  AT  1  program  required  to  submit  Major 

Acquisition  Information  System  (MAIS)  Quarterly  Reports  (MQR).  In  the  September 

2008  MQR,  the  GCSS-MC  program  reported  it  was  likely  to  breach  in  the  areas  of  cost 

and  schedule  and  would  fail  to  achieve  IOC  within  five  years  of  MS  A  [43].  A  Critical 

Change  Team  (CCT)  was  formed  to  evaluate  the  program  on  cost,  schedule,  and 

technical  performance.  The  CCT  determined  that  the  program  would  breach  cost  and 
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schedule  and  recommended  that  the  program  rebaseline  and  revise  its  acquisition  strategy 
to  include  a  two  phase  implementation  approach.  The  Block  1  program  would  be  split 
into  two  releases.  Release  1 . 1  would  provide  the  enterprise  functional  baseline  and  allow 
users  to  access  the  system  from  anywhere  in  the  world  as  long  as  they  had  a  high  speed 
internet  connection.  Release  1 .2  would  provide  access  to  users  who  were  deployed  in  an 
austere,  poor  communication  environment.  Figure  25  shows  the  proposed  rebaseline 
schedule  compared  to  the  MS  B  baseline  schedule. 
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Figure  25.  GCSS-MC  CCT  Schedule  Comparisons.  From  [43] 


The  CCT  recommendation  drastically  changed  the  acquisition  strategy  of  the 
program.  The  new  schedule  allowed  the  program  to  defer  the  harder,  technically 
challenging  aspects  of  the  program  (data  synchronization  and  cross  domain  solution)  to  a 
later  release  while  providing  the  baseline  functional  capability  of  the  system  sooner  to  the 
user.  With  the  accepted  new  CCT  schedule  shown  in  Figure  26,  the  GCSS-MC  program 
was  on  a  path  to  achieve  a  new  MS  C  date  in  first  quarter  FY2010. 
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Figure  26.  GCSS-MC  CCT  Rebaseline  Schedule 
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Preparations  for  MS  C  were  now  ongoing  in  accordance  with  the  new  CCT 
schedule.  Even  with  the  revised  schedule,  the  program  office  realized  that  MS  C  would 
not  be  achievable  as  planned  in  first  quarter  FY2010.  The  November  2009  System 
Engineering  Plan  being  prepared  for  MS  C  depicted  a  modified  schedule,  shown  in 
Figure  27,  that  delayed  both  MS  C  and  IOC  by  six  months  still  within  the  six  month 
threshold  values. 
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Figure  27.  GCSS-MC  MS  C  System  Engineering  Plan  Schedule 

The  February  2010  AS/AP  prepared  for  the  MS  C  event  kept  most  of  the  dates 
stable.  The  FRP  was  renamed  to  Full  Deployment  Decision  (FDD)  and  was  delayed  by 
six  months.  The  FOC  was  renamed  to  Full  Deployment  (FD).  The  dates  in  Figure  28 
show  that  the  program  is  now  stabilizing  and  preparing  to  go  into  a  Functional  User 
Evaluation  in  second  quarter  of  2010. 
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Figure  28.  GCSS-MC  MS  C  AS/AP  Schedule 


The  April  2010  APB  prepared  for  the  MS  C  event  is  shown  in  Figure  29.  IOC 
was  deleted;  however  Release  1  of  GCSS-MC  was  initially  fielded  to  the  Marines  in  III 
MEF  during  the  Field  User  Evaluation  (FUE)  event  and  could  be  considered  an  IOC  for 
all  intents  and  purposes.  All  other  dates  have  stabilized  and  the  GCSS-MC  program 
office  is  on  track  to  fully  field  the  Block  1  capability  to  the  Marine  Corps  in  second 
quarter  FY2013. 
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APB  SCHEDULE  (Apr  2010)  Objective  Dates  Shown 
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Figure  29.  GCSS-MC  MS  C  APB  Schedule 


The  IOC  and  FOC  dates  in  the  2003  ORD  were  very  ambitious  and  it  was 
unrealistic  to  believe  that  IOC  could  be  achieved  in  2004  and  FOC  could  be  achieved  in 
2006.  It  was  not  until  second  quarter  2010  that  users  could  access  the  system  and  it  will 
not  be  until  second  quarter  2013  that  GCSS-MC  will  be  fielded  to  the  entire  Marine 
Corps,  about  six  and  a  half  years  after  the  original  dates  specified  in  the  ORD. 

G.  CHAPTER  SUMMARY 

The  GCSS-MC  Analysis  of  Alternatives  analyzed  five  alternative  solutions  of 
Status  Quo,  Upgrade  Legacy,  Custom  Implementation,  COTS,  and  Outsource.  The 
Program  Office  chose  a  COTS  solution  as  it  met  the  most  intended  scope  of  the  system 
and  had  the  highest  return  on  investment  [33]. 

Requirements  have  been  stable  in  the  GCSS-MC  program  and  a  traceability  effort 
has  ensured  that  all  requirements  are  traceable  and  are  being  met.  The  GCSS-MC 
functional  and  technical  requirements  are  very  unique  and  extensive  customization  of  the 
COTS  software  is  required.  Only  83%  of  the  programs  requirements  can  be  met  by  the 
COTS  ERP  software  out-of-the-box.  Customization  of  the  ERP  software  using  RICE 
objects  is  critical  to  meeting  all  of  its  functional  and  technical  requirements.  The 
development  of  the  RICE  objects  has  introduced  a  complexity  that  has  caused  the 
program  to  overrun  the  budget  and  delay  the  schedule.  The  Program  Office  has 
recognized  that  the  complexity  in  the  program  lies  in  the  technical  challenges  and  has 
separated  the  development  effort  into  two  releases.  This  strategy  allows  the  basic 
functionality  to  be  delivered  to  the  user  sooner  than  the  more  technically  challenging 
multi-instance  capability. 
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When  the  GCSS-MC  program  chose  a  COTS  product  as  their  material  solution  to 
modernize  the  Marine  Corps  logistics  IT  systems  [33],  the  belief  was  that  a  product  used 
widely  in  industry  could  easily  be  adapted  to  suit  the  business  practices  of  the  United 
States  Marines.  Throughout  the  development  of  GCSS-MC,  every  time  a  new  schedule 
would  appear  in  either  a  systems  engineering  or  acquisition  document,  the  dates  for  key 
acquisition  events  would  move  to  the  right.  Granted,  there  was  an  unexpected  change  in 
the  system  integrator,  and  that  by  its  very  nature  can  cause  a  schedule  delay,  but  the 
technical  challenges  were  not  anticipated  and  feasible  schedules  could  not  be  developed. 

In  retrospect,  the  original  IOC  and  FOC  dates  in  the  2003  ORD  were  very 
ambitious.  It  was  not  until  second  quarter  2010  that  users  could  access  the  system  and  it 
will  not  be  until  second  quarter  2013  that  GCSS-MC  will  be  fielded  to  the  entire  Marine 
Corps,  about  six  and  a  half  years  after  the  original  dates  specified  in  the  ORD. 
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IV.  RESEARCH  ANALYSIS 


A.  INTRODUCTION 

The  development  and  implementation  of  DoD  Service  Component  ERP  logistics 
IT  systems  has  a  history  of  cost  overruns  and  schedule  delays.  All  are  trying  to 
modernize  their  logistics  IT  systems.  How  do  the  ERP  implementations  of  the  four 
Services  compare?  Are  they  trying  to  implement  the  same  functionality?  Are  they  all 
facing  the  same  challenges?  If  so,  why  should  the  DoD  spend  as  much  money  as  they 
have  in  six  systems  when  one  system  could  be  developed  to  be  used  by  all  four  Services? 

In  the  case  of  the  GCSS-MC  program,  there  were  technical  challenges  to 
overcome.  A  detailed  look  at  the  GCSS-MC  program  reveals  a  level  of  complexity  that 
was  unexpected  and  not  factored  into  the  development  effort.  What  lessons  are  learned 
and  how  can  those  lessons  apply  to  future  ERP  developments? 

B.  SERVICE  COMPONENT  FUNCTIONAL  ANALYSIS 

Each  Service  Component  has  designed  their  ERP  system  to  provide  logistics 
chain  management  to  modernize  their  logistics  IT  systems.  The  DoD  has  adopted  a 
methodology  called  the  Supply  Chain  Operations  Reference  (SCOR)  model  to  help 
describe  the  business  activities  associated  with  all  phases  of  satisfying  a  customer's 
demand  [44],  SCOR  was  first  investigated  by  the  Navy  as  part  of  a  supply-chain 
management  project  in  1997—98  [44],  All  four  Services  have  applied  the  SCOR  model 
in  some  way.  The  Marine  Corps  has  used  it  as  a  guide  to  help  consolidate  its  information 
systems,  the  Navy  has  used  it  to  help  benchmark  its  process  perfonnance,  the  Anny  has 
studied  its  best  commercial  practices,  and  the  Air  Force  has  incorporated  some  of  its 
metrics  in  its  organizational  scorecard  effort  [44].  The  DoD’s  use  of  the  SCOR  model 
may  explain  why  there  is  so  much  commonality  between  the  Service  ERP  efforts. 

The  SCOR  model  uses  the  high  level  functions  of  Plan,  Source,  Make,  Deliver, 
and  Return  [44].  The  SCOR  definition  of  these  functions  were  very  generic  but  could  be 
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mapped  loosely  to  the  ERP  functionality  of  the  Service  Components.  Figure  30  shows 
the  functional  hierarchy  of  the  ERP  functions  as  they  pertain  to  the  SCOR  high-level 
functions. 


Figure  30.  Functional  Hierarchy 


An  analysis  of  the  functional  needs  of  each  Service  shows  that  in  10  out  of  13 
categories,  functionality  is  common  in  two  or  more  of  the  Services  and  in  about  half  of 
the  categories  functionality  is  common  in  about  half  of  them.  This  implies  that  the 
Service  Components  have  been  developing  redundant  capability  and  have  been  spending 
billions  of  dollars  to  solve  the  same  problems.  Service  Component  functions  are  broken 
out  by  category  in  Table  12  and  a  comparison  of  those  functions  show  that  a 
commonality  exists  across  many  of  the  development  efforts. 
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Table  12 


Service  Component  Functional  Comparison 


Top 

Level 

Function 

# 

Category 

Army 

Navy 

Air  Force 

Marine  Corps 

Plan 

1 

Manage 

Supply 

Supply  Support 
Activity 

Unit  Level 

Supply 

Order 

fulfillment 

Demand  and 
supply  planning 

Ammunition 

Wholesale  and 
retail  supply 

Supply 

forecasting  and 

demand 

processing 

Order 

fulfillment 

Demand 

planning 

Supply 

Retail  and 
wholesale 
supply 

2 

Manage 

Acquisition 

Acquisition 

Events 

management 

Acquisition 

Acquisition 

3 

Manage 

Warehouse 

Asset 

management 

Property  book 

Warehouse 

management 

Inventory 

management 

Warehousing 

4 

Manage 

Health  and 
Safety  Records 

Environmental 
health  and  safety 

Health 

5 

Manage 

Personnel 

Personnel 

administration 

Manpower 

systems 

6 

Manage 

Engineering 

Support 

Engineering 

Engineering 

Source 

7 

Schedule 

Maintenance 

Materiel 

maintenance 

Aviation  and 

Ground 

Maintenance 

Intermediate- 

Level 

maintenance 

Maintenance 

management 

Maintenance 
and  repair 

Maintenance 

8 

Manage 

Finances 

Financial 

management 

Finance  support 
to  tactical 
supply  and 
maintenance 

Cost 

management 

Financials 

Billing 

Budgeting 

Costing  and 

Cost  planning 

Budget  exhibits 

Financial 

management 

Accounting 

Financial 

management 
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Top 

Level 

Function 

# 

Category 

Army 

Navy 

Air  Force 

Marine  Corps 

9 

Administer 

Contracts 

Procurement 

Contract 

awards 

Procurement 

Make 

10 

Manage 

Quality 

Quality 

management 

11 

Manage 

Calibration 

Calibration 

management 

Deliver 

12 

Manage 

Transportation 

Transportation 

Transportation 

13 

Manage 

Training 

Training 

With  so  much  commonality  between  the  ERP  development  efforts,  a  case  can  be 
argued  that  the  DoD  should  pursue  only  one  ERP  solution  that  can  be  used  by  all  Service 
Components. 

C.  SERVICE  COMPONENT  ERP  DEVELOPMENT  ANALYSIS 

All  DoD  ERP  development  efforts  addressed  in  this  thesis  are  trying  to  modernize 
their  logistics  chain  management  IT  infrastructure.  All  are  going  through  the  same  basic 
System  Engineering  process  steps  of  conceptual  design,  preliminary  design,  detail  design 
and  development,  production/construction,  and  operational  use  and  system  support  [45]. 
All  have  experienced  the  same  challenges  as  they  try  to  implement  similar  capability  and 
functionality. 

The  modernization  of  logistics  IT  systems  is  a  necessity  as  some  of  the  legacy 
systems  are  approaching  being  in  service  close  to  40  years.  Many  of  the  programming 
languages  have  been  in  use  for  many  years,  some  for  decades,  and  require  very  senior 
software  engineers  to  maintain  them.  Most  if  not  all  of  these  systems  were  built  in  a 
stove-piped  fashion  with  no  common  interfaces  making  it  difficult  to  track  the 
authoritative  data  source  for  items  and  necessary  to  keep  the  same  information  in 
multiple  systems.  All  four  Service  Components  have  the  need  to  modernize  their 
logistics  IT  infrastructure  yet  all  are  independently  tackling  the  job. 
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There  are  many  ways  to  develop  a  new  logistics  IT  infrastructure.  New  programs 
can  be  written  with  current  modem  day  programming  languages.  There  are  many 
programs  that  specialize  in  one  aspect  of  logistics  management.  All  four  Service 
Components  did  not  go  either  of  these  routes;  instead  they  all  chose  an  ERP  COTS 
solution.  This  decision  allows  one  suite  of  software  to  be  used  for  not  only  specialized 
logistics  functions,  but  allows  management  of  the  entire  logistics  chain.  This  provides 
cross  functionality  between  the  ERP  modules  and  reduces  the  need  for  development  of 
additional  stove-pipe  systems.  All  four  Service  Components  chose  a  separate  ERP 
solution  and  decided  to  implement  their  system  independent  from  one  another. 

Implementation  of  an  ERP  in  its  entirety  is  a  very  large  undertaking.  All  Service 
Components  scoped  the  size  of  the  ERP  development  effort  into  smaller  increments. 
This  incremental  methodology  allows  a  much  more  manageable  effort  with  opportunities 
to  add  on  to  the  baseline  system  at  a  later  date.  Not  all  of  the  Service  Components  started 
with  the  same  functionality  in  their  initial  baseline,  however.  If  a  narrow  enough  scope  is 
defined,  it  may  be  possible  to  focus  development  on  that  capability  for  use  by  all  four 
Service  Components. 

The  use  of  ERP  COTS  software  allows  the  user  to  begin  development  with  any 
particular  functionality  inherent  in  the  complete  software  suite.  All  are  providing,  or 
planning  to  provide,  much  of  the  same  functionality  such  as  ordering  a  part,  scheduling 
maintenance,  tracking  assets,  tracking  finances,  planning  and  tracking  distribution,  and 
planning  cost.  While  each  Service  Component  may  have  started  their  development 
efforts  with  different  initial  capabilities  in  mind,  ultimately  the  intent  is  to  focus  on 
complete  logistics  chain  management,  a  common  capability  that  each  Service  Component 
needs. 

The  intent  of  each  Service  Component  is  to  replace  their  existing  logistics  IT 

systems  with  a  modernized  state  of  the  art  logistics  chain  management  IT  infrastructure. 

This  entails  the  movement  of  information  from  the  legacy  IT  system  to  the  ERP  system. 

Legacy  data  must  be  cleaned,  reformatted,  and  moved  in  a  consistent  manner  from  each 

of  the  legacy  systems.  This  allows  the  ERP  system  to  view  legacy  data  and  maintain  a 

history  of  information  regarding  logistics  transactions  from  the  past.  Each  Service 
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Component  has  to  move  legacy  data  to  the  new  ERP  system.  This  is  a  very  consistent, 
rigorous,  and  repeatable  operation  that  can  be  reused  over  and  over  again,  not  just  by  one 
of  the  Service  Components,  but  shared  by  all  to  ensure  a  consistent  transfer  of  data. 

Once  the  ERP  system  has  been  developed  it  must  be  fielded  to  the  user.  All 
Service  Components  have  many  users  in  several  geographic  locations.  All  require  users 
to  be  “moved”  from  using  the  legacy  system  to  using  the  new  ERP  system.  This  requires 
extensive  training  of  not  only  the  new  ERP  system  but  the  understanding  of  how  to 
perform  legacy  processes  within  the  new  ERP  system.  Once  again,  this  is  a  very 
consistent,  rigorous,  and  repeatable  operation  that  can  be  reused  and  shared  by  all  Service 
Components  to  ensure  that  all  users  get  trained  in  a  uniform  and  consistent  manner. 

Summarized  in  Table  13,  there  are  many  commonalities  between  all  of  the  ERP 
development  efforts.  It  can  be  argued  that  this  commonality  presents  a  case  for  the  DoD 
to  pursue  only  one  ERP  solution  that  can  be  used  by  all  Service  Components. 


Table  13. 

Service  Component  Commonality 

Common  Item 

Description 

Modernization  of  Logistics  IT 

-  Replace  very  old  logistics  IT  systems. 

-  Unsupportable  legacy  systems. 

-  Stove-piped  legacy  systems,  data  not  easily 

transferred. 

Using  ERP  Concepts 

-  Cross  functionality  between  logistics  management 

functions. 

Incremental  Development 

-  Multiple  releases. 

-  Reduce  scope  to  a  manageable  level. 
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Common  Item 

Description 

Functionality 

-  Ordering  a  part. 

-  Scheduling  maintenance. 

-  Tracking  assets. 

-  Tracking  finances. 

-  Planning  and  tracking  distribution. 

-  Planning  cost. 

Legacy  Data  Conversion 

-  Data  movement  from  legacy  to  ERP  system. 

Legacy  System  Cutover 

-  “Move”  users  from  using  the  legacy  system. 

-  User  ERP  training. 

-  User  process  training. 

D.  GCSS-MC  IMPLEMENTATION  ANALYSIS 

The  GCSS-MC  ERP  development  effort  has  had  many  challenges  since  its 
inception  in  2003.  Review  of  other  DoD  services  ERP  development  efforts  within  the 
Air  Force,  Army,  and  Navy  show  that  the  schedule  delays  encountered  by  the  GCSS-MC 
program  are  “normal.”  The  GAO  has  written  several  reports,  many  referenced  in  this 
thesis,  regarding  the  challenges  encountered  in  ERP  developments  within  DoD  and  there 
are  many  factors  involved  ranging  from  unrealistic  schedule  planning  to  unexpected 
design  complexity  of  the  ERP  system. 

As  the  GCSS-MC  program  progressed  through  development,  more  and  more 
information  was  learned  regarding  the  time  required  to  design,  build,  and  test  the  system. 
At  each  major  milestone  or  critical  stage  of  the  GCSS-MC  program  the  schedule  was 
modified.  Figure  31  shows  that  IOC  was  delayed  6.5  years  and  FOC  was  delayed  6  years 
from  the  original  GCSS-MC  ORD  estimate.  The  delays  were  enough  to  cause  the 
program  to  breach  schedule  and  fail  to  reach  MS  C  five  years  after  achievement  of  MS  A. 
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Marine  Corps  Trend  Data 
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Figure  31.  Marine  Corps  Schedule  Trend 


The  GCSS-MC  program’s  acquisition  approach  was  modified  several  times  due  to 
systems  integrator  issues  and  program  complexity.  While  the  core  requirements 
remained  stable  throughout  development,  the  overhead  of  implementing  financial 
requirements  increased  the  complexity  of  the  effort.  The  implementation  of  the  core 
requirements  required  a  logical  split  between  functional  availability  to  the  enterprise 
users  and  accessibility  to  the  deployed  users.  It  was  the  complexity  of  the  RICE  objects, 
in  particular  the  RICE  objects  for  data  synchronization  and  SIPRNET,  that  created  a 
delay  in  schedule,  drove  an  increase  in  cost,  redefined  the  scope  size  of  the  effort  and 
influenced  the  program  to  adopt  a  two  release  strategy  for  the  first  block  of  GCSS-MC 
capability.  This  two  release  strategy  reinforced  the  philosophy  that  designing  and 
implementing  smaller  increments  of  capability  over  short  periods  of  time  allows 
capability,  even  if  it  is  reduced  from  the  original  plan,  to  be  fielded  earlier  to  the  user. 
The  GCSS-MC  Program  challenges  are  summarized  in  Table  14. 
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Table  14.  GCSS-MC  Program  Challenges 


Challenge 

Description 

RICE  Objects 

-  Data  conversion  and  interface  complexity. 

Schedule 

-  Delays  due  to  unexpected  complexity. 

Cost 

-  Increase  cost  due  to  schedule  delays. 

Scope  Size 

-  Scope  split  into  smaller  increments  due  to  schedule 

delays. 

Requirements  Definition 

-  Additional  requirements  due  to  unexpected 

financial  requirements. 

E.  CHAPTER  SUMMARY 

There  are  many  commonalities  between  the  four  Service  Components  ERP 
development  efforts.  All  have  chosen  an  ERP  solution  to  modernize  their  logistics  IT 
systems.  All  have  very  similar  functionality  being  developed  and  implemented  in 
multiple,  reduced  scope  releases.  All  have  to  convert  data  from  legacy  systems  and  all 
have  to  train  users  on  how  to  use  the  new  ERP,  as  well  as  the  corresponding  business 
processes. 

All  four  Services  have  experienced  many  similar  challenges  that  have  caused  cost 
overruns  and  schedule  delays  for  all  the  programs.  These  overruns  and  delays  are  due  to 
program  complexity  in  the  areas  of  data  conversion  and  interface  development  along  with 
unexpected  requirements  that  are  required  within  the  financial  community.  The  question 
becomes  why  should  the  DoD  spend  as  much  money  as  they  have  in  six  systems  when 
maybe  one  system  could  be  developed  to  be  used  by  all  four  Services? 
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V.  CONCLUSIONS  AND  RECOMMENDATIONS 


A.  CONCLUSIONS 

This  research  focused  on  DoD  ERP  implementation  efforts  ongoing  in  the  Army, 
Navy,  Air  Force,  and  Marine  Corps.  A  macro-level  review  of  six  DoD  ERP 
implementations  provided  a  historical  perspective  reflecting  the  difficulty  all  have  had  in 
developing  their  respective  ERP  systems.  A  micro-level  review  of  the  GCSS-MC 
program  identified  systems  engineering  challenges  the  program  has  faced.  The 
conclusion  is  that  all  Service  Components  have  similar  requirements  and  all  struggle  with 
development  of  their  respective  ERP  solution.  Much  money  has  been  and  continues  to  be 
spent  on  ERP  implementation.  Each  implementation  has  taken  much  more  time  than  was 
originally  planned.  It  is  important  for  the  DoD  to  take  a  hard  look  at  how  the  current 
ERP  solutions  have  been  developed  and  determine  alternative  ways  to  develop  similar 
systems  in  the  future.  The  DoD  cannot  afford  the  billions  of  dollars  that  have  been  spent 
on  multiple  system  developments  and  needs  to  figure  out  a  way  to  consolidate  efforts 
between  the  Service  Components.  These  consolidated  efforts  may  provide  not  only  an 
expedited  system  development  effort  but  also  a  common  system  that  can  be  centrally 
managed  and  used  to  breakdown  the  unique  stove  pipe  processes  within  each  Service  and 
transform  logistics  chain  management  as  it  is  know  today. 

Table  15  provides  a  summary  of  the  recommended  ERP  implementation 
methodology  activities. 
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Table  15. 


ERP  Implementation  Recommendation  Summary 


Effort 

Actual  (Today) 

Recommended 

DoD  ERP 

-  Separately  managed  efforts 

-  Single  centrally  managed 

Implementation 

by  four  Service  Components. 

effort. 

Build  and  Design 

-  Individual  System  Integrator 

-  Multiple  System  Integrator 

contracts. 

contracts. 

-  Multiple  System  Integrators 

-  Single  System  Integrator 

and  implementation 

and  implementation 

methodologies. 

methodologies. 

RICE  Objects 

-  Severe  customization. 

-  Conform  to  core  software 

functionality  and  change 

business  processes  of  each 

Service. 

Test 

-  Decentralized. 

-  No  change. 

Fielding 

-  Decentralized. 

-  Centralized  cutover 

-  Unique  cutover  processes. 

processes. 

-  Unique  training  processes. 

-  Centralized  training 

processes. 

PDSS 

-  Decentralized. 

-  Centralized. 

-  Multiple  PDSS  contracts. 

-  Single  Contract. 

-  Multiple  configurations. 

-  Single  configuration. 

-  Multiple  release 

-  Single  release  management 

management  efforts. 

process. 
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Each  Service  Component  of  the  DoD  is  essentially  trying  to  accomplish  the  same 
thing  by  modernizing  aging  logistics  IT  systems  and  streamlining  multiple  systems  into 
one  complete,  coherent,  and  accurate  logistics  chain  management  system.  All  have 
common  implementation  strategies  but  each  has  unique  requirements  that  represent  the 
core  business  processes  of  each  Service.  All  have  experienced  similar  program 
management  and  systems  engineering  challenges  recognized  by  the  GAO  and  continue  to 
struggle  with  development  of  their  ERP  systems. 

The  GAO  determined  there  were  many  weak  areas  in  each  of  the  DoD  ERP 
efforts  such  as: 

•  Unsuccessful  implementation  of  Enterprise  Architectures  and  CONOPS, 

•  Lack  of  MNS  in  early  pilot  programs, 

•  Lack  of  I  V&V  implementation, 

•  Technical  challenges  in  implementation  of  system  interfaces  and  data 
conversion  from  legacy  systems, 

•  Requirements  documentation  not  clearly  linked  together  or  aligned  to 
DoD’s  Enterprise  Transition  Plan, 

•  Weak  management  of  earned  value  and  risk. 

Many  of  the  GAO  identified  weak  areas  impact  each  Service’s  ability  to 
accurately  determine  the  time  it  will  take  to  design,  build,  test,  and  field  their  respective 
ERP  system.  An  example  is  GCSS-MC’s  history  of  continuing  to  revise  the  development 
schedule  at  almost  every  major  acquisition  milestone  and  new  release  of  system 
engineering  documentation.  The  government  inherently  has  a  lack  of  knowledge  of  how 
ERP  systems  work  and  does  not  understand  well  enough  the  functional  gaps  between  the 
COTS  software  and  the  Service  Components  requirements.  In  addition,  there  are 
potential  scope  size  challenges  that  may  require  development  efforts  be  broken  down  into 
smaller  manageable  pieces  in  order  to  decrease  the  complexity  of  the  effort.  The  GCSS- 
MC  program  recognized  the  complexity  and  technical  challenges  in  customizing  the 
COTS  product  and  moved  the  RICE  objects  for  the  cross  domain  solution  and  data 
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synchronization  capability  into  Release  1.2  allowing  the  GCSS-MC  program  to  field  the 
basic  capability  of  supply  and  maintenance  management  sooner  to  the  war  fighter  and 
speed  up  the  process  of  eliminating  the  legacy  supply  and  maintenance  systems. 

The  application  of  a  COTS  product  in  a  DoD  environment  is  much  different  from 
that  in  the  private  sector.  COTS  products  do  not  provide  unique  DoD  or  Service 
Component  functional  and  technical  capabilities  to  support  things  such  as  mobility  of 
troops  and  poor  communication  networks  in  austere  environments.  This  is  much 
different  than  stationary  brick  and  mortar  buildings  with  solid  and  stable  communication 
links.  Therefore,  the  perception  of  buying  a  COTS  product  to  minimize  development 
effort  is  exactly  that,  a  perception.  In  addition  to  not  supporting  the  functional  and 
technical  requirements,  the  COTS  product  does  not  provide  the  unique  Service 
Component  business  processes  nor  does  it  provide  the  unique  DoD  SFIS  and  JFMIP 
financial  requirements.  The  implementation  of  the  unique  DoD  requirements  translates 
to  a  large  development  effort  in  terms  of  customization  and  configuration. 

All  Service  Component  ERP  development  efforts  discussed  in  this  thesis  are 
similar  in  nature  and  are  trying  to  accomplish  the  same  end  goals.  The  functional 
analysis  shows  that  the  Service  Component’s  are  developing  redundant  capability.  The 
GAO  has  identified  several  weaknesses  in  each  independent  ERP  development.  The 
technical  challenges  that  GCSS-MC  has  faced  are  common  across  the  DoD.  Would  it 
make  sense  to  develop  only  one  system  for  use  by  all  of  the  Service  Components  that 
would  address  all  of  the  GAO  identified  weaknesses  and  minimize  the  functional  and 
technical  challenges  experienced  by  the  DoD? 

B.  RECOMMENDATIONS 

There  is  a  common  functional  capability  desired  by  all  four  Services  as  they  all 
try  to  achieve  the  same  goal  of  modernizing  their  logistics  IT  systems.  All  four  Services 
have  already  determined  and  chosen  the  COTS  ERP  product  as  their  IT  solution.  The 
GCSS-MC  Program  AOA  has  shown  that  a  COTS  ERP  product  is  the  desired 
implementation  method  since  it  uses  industry  best  practices  and  best  meets  the  defined 
capability  of  the  Marine  Corps  [33].  A  COTS  ERP  system,  by  its  very  nature,  provides  a 
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single  integrated  package  of  capability  that  is  common  to  all  four  Services.  With  each 
individual  DoD  ERP  development  effort  referenced  in  this  thesis  demonstrating  severe 
cost  overruns  and  schedule  delays,  the  recommendation  is  to  develop  a  single  ERP 
system  that  can  be  used  by  all  four  Service  Components. 

Developing  a  single  integrated  COTS  ERP  solution  for  all  four  Services  is 
consistent  with  and  satisfies  much  of  the  intent  of  the  DoD  Information  Enterprise 
Strategic  Plan,  2010-2012  [46].  The  intent  of  the  Strategic  Plan  is  to  share  infonnation 
across  DoD  and  with  mission  partners,  in  summary  this  includes:  the  information  itself; 
the  Department’s  management  over  the  information  life  cycle;  the  processes  associated 
with  managing  information  to  accomplish  the  DoD  mission  and  functions;  activities 
related  to  designing,  building,  populating,  acquiring,  managing,  operating,  protecting  and 
defending  the  information  enterprise;  and  sharing  of  related  information  resources  such 
as  personnel,  funds,  and  equipment  [46].  Being  a  shared  system  used  across  DoD,  a 
single  integrated  COTS  ERP  solution  provides  everything  the  Strategic  Plan  intends  and 
provides  the  basis  for  the  following  recommended  implementation  methodology. 

Development  of  a  single  integrated  ERP  system  provides  many  advantages  such 
as  : 

•  Reduction  of  the  number  of  logistics  IT  systems  to  maintain  -  saves 
billions  of  development  and  sustainment  dollars, 

•  Asset  visibility  across  Services  -  locate  and  provide  gear  to  war  fighter 
faster  and  more  efficiently, 

•  Shared  data  in  same  place  -  logistics  data  available  to  all  Services  to  make 
better  infonned  Command  and  Control  decisions, 

•  Common  transportation  and  distribution  -  reduce  number  of  deliveries  and 
get  gear  to  war  fighter  quicker, 

•  Procurement  streamlining  -  shared  transactional  procurement  data  to 
eliminate  unnecessary  duplication  of  gear, 
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•  Consistent  processes  -  train  all  DoD  supply  personnel  on  same  processes 
and  provide  ability  for  Services  to  move  personnel  between  Services. 

To  develop  such  a  system,  a  Lead  Service  or  external  entity  could  act  as  the 
Program  Office  and  manage  the  entire  life  cycle  support  of  the  system.  The  ERP  COTS 
solution  should  be  developed  using  centralized  design,  build,  and  sustainment  efforts  for 
all  of  the  Services  and  decentralized  test  and  field  efforts  within  each  of  the  Services. 
Centralized  design  and  build  efforts  ensure  common  requirements  are  defined  and 
implemented  through  a  common  infrastructure  and  establishes  a  solid  baseline  for 
commonality  across  the  Service  Components.  Decentralized  test  and  fielding  efforts  are 
required  to  account  for  the  unique  networks  of  each  Service  as  well  as  the  number  of 
geographic  locations  and  number  of  systems  to  be  subsumed.  The  ERP  development 
activities  of  Design,  Build,  Test,  Field,  and  Sustain  are  depicted  in  Figure  32  and 
discussed  in  the  following  sections. 
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Figure  32.  ERP  Development  Recommendation 


1.  Centralized  Design 

The  design  of  the  ERP  solution  needs  to  address  requirements  from  all  four 
Service  Components.  Technical  requirements  should  be  fairly  standard.  These  include 
the  ability  to  access  the  system  from  any  environment  with  excellent  or  poor 
communication  networks  and  the  ability  to  handle  a  very  large  number  of  users.  The 
functional  requirements  should  also  be  fairly  standard,  that  is,  the  same  business 
processes  to  be  used  by  all  the  Services.  Examples  are  the  ability  to  order  a  part, 
schedule  maintenance,  or  track  assets.  However,  this  presents  a  tremendous  change 
management  issue  for  all  of  the  Services  since  the  functional  requirements,  when 
standardized,  will  most  likely  not  resemble  the  current  way  business  is  being  done  in  any 
of  the  four  Services.  The  advantage  is  that  a  common  language  for  logistics  management 
is  established,  standard  processes  are  exercised,  and  all  Services  conform  to  one  system. 
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Now  consolidated  training  can  be  provided  to  all  Services  and  users  from  each  Service 
can  actually  perform  the  function  on  behalf  of  a  sister  Service  in  time  of  need.  This 
means  very  detailed  planning  is  required  up  front  to  ensure  the  common  set  of  functional 
requirements  address  all  of  the  Services  functional  needs. 

2.  Centralized  Build 

The  build  of  the  ERP  solution  will  be  very  data  intensive.  RICE  objects  are  a  big 
cause  for  concern  because  of  the  complexity  they  introduce.  Any  RICE  objects  that  are 
common  across  the  Services  should  be  incorporated  into  the  core  baseline  ERP  software. 
To  minimize  the  development  of  RICE  objects,  the  developer  should  go  to  great  lengths 
to  use  existing  functionality  already  inherent  within  the  ERP  COTS  software,  however, 
there  will  be  some  RICE  interface  objects  required  since  not  all  Services  connect  to  the 
same  internal  and  external  systems.  There  may  also  be  some  unique  reporting 
requirements  for  each  Service  Component  and  customized  reports  may  be  required  to  be 
developed. 

There  are  several  other  commonalities  that  can  be  obtained  during  the  build  effort. 
The  use  of  a  common  data  conversion  template  allows  a  rigorous,  repeatable,  process  to 
convert  data  from  a  legacy  system.  The  development  of  a  common  data  dictionary 
ensures  that  all  data  elements  are  defined  once  and  used  many  times  by  all  Service 
Components  in  a  standardized  way. 

3.  Decentralized  Test 

Test  efforts  are  decentralized  and  allocated  to  the  respective  Service  Component 
for  implementation.  This  is  due  to  the  uniqueness  of  the  network  for  each  Service  and 
accommodates  the  unique  interfaces  that  each  Service  must  be  able  to  test.  This  may 
make  it  difficult  to  maintain  a  single  baseline  for  all  four  Services  since  four  individual 
test  efforts  will  be  ongoing  and  may  discover  problems  required  to  be  fixed  in  the  core 
baseline.  This  requires  an  extreme  amount  of  coordination  between  the  Services  to 
manage  the  configuration  of  the  baseline  software. 
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4.  Decentralized  Fielding 

Fielding  efforts  are  decentralized  and  allocated  to  the  respective  Service 
Component  for  implementation.  Each  Service  has  a  unique  number  of  locations  and  a 
unique  number  of  systems  to  convert  and  is  responsible  for  implementation  of  fielding  at 
a  local  level. 

Each  location  demands  not  just  training  users  on  how  to  use  the  new  system  but 
training  users  on  how  the  new  system  relates  to  the  old  system  processes.  This  is  part  of 
the  change  management  effort  and  it  is  important  to  convey  the  relationship  between  the 
old  and  new  processes.  Local  Field  Service  Representatives  will  also  be  available  to 
assist  local  users  on  how  to  use  the  system  when  the  new  ERP  system  is  initiated  for  the 
first  time. 

Each  location  requires  conversion  of  unique  legacy  system  data  into  the  new  ERP 
system.  All  data  from  the  legacy  system  must  be  cleaned,  reformatted,  and  converted  for 
accuracy  and  ability  to  be  retrieved  from  the  new  system. 

Even  with  Service  unique  location  and  legacy  system  conversion  requirements, 
standardized  processes  can  be  still  be  implemented  across  the  Services.  Cutover  and 
training  processes  can  be  standardized  to  be  repeatable  and  with  the  appropriate  data 
templates,  data  conversion  can  also  be  standardized. 

5.  Centralized  Sustainment,  Post-Deployment  System  Support  (PDSS) 

After  the  ERP  solution  has  been  designed,  built,  tested,  and  fielded,  the  system 
will  need  to  be  sustained  and  maintained.  Configuration  and  Release  Management 
become  very  important  as  the  system  is  used  and  patches,  enhancements,  and 
modifications  are  made  to  the  system.  A  Help  Desk  is  established  for  user  support  in 
times  of  technical  assistance,  training,  or  problem  solving  in  general.  Centralization  of 
PDSS  means  a  single  contract  is  needed  to  maintain  support  of  ERP  efforts  for  all  four 
Services. 

The  above  five  activities  provide  a  potential  method  to  develop  a  single  ERP 
system  for  logistics  chain  management  in  the  DoD.  At  a  glance,  the  recommendation  to 
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develop  a  single  ERP  system  across  Services  appears  to  have  merit,  however,  even  a 
single  system  development  effort  will  have  several  challenges  that  need  to  be  analyzed, 
socialized,  and  bought  into  by  the  Service  Components. 

C.  AREAS  TO  CONDUCT  FURTHER  RESEARCH 

This  research  can  be  further  conducted  in  a  few  areas.  These  areas  include: 

•  ERP  System  Deployment  Options.  Analysis  can  be  conducted  on  how 
best  to  deploy  an  ERP  system.  This  should  include  not  only  consideration 
of  the  DoD  acquisition  process  but  also  the  methodology  used  by  private 
industry. 

•  Single  DoD  ERP  Logistics  System  Feasibility.  This  thesis  recommended 
a  single  system  to  be  centrally  managed  and  developed  and  used  across  all 
four  Services,  but  how  feasible  is  that?  Are  the  individual  Services 
willing  to  give  up  their  long  time  used  stove  piped  business  processes  for  a 
common  way  to  do  logistics  business  across  the  DoD? 

•  ERP  System  Scoping  Options.  Analysis  can  be  conducted  to  determine 
the  best  approach  to  “right  size”  the  initial  scope  for  a  universally 
developed  DoD  ERP  logistics  chain  management  implementation.  What 
is  the  right  functionality  to  be  developed  for  all  Service  Components  to 
initially  start  with  and  how  is  that  functionality  detennined? 
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